Submitted On 08-JUL-1999
mthornton The existing setReadOnly operation could be described as "remove all write
access". An "add all write access" would be just as well
defined. The argument in the evaluation could also be used to reject the
current setReadOnly method. In fact it could also be used against all the
existing file creation methods.
Submitted On 03-SEP-1999
tjdennis You CAN'T DELETE a READ-ONLY FILE!!!!
This suggestion of deleting the file and creating
a new one is not valid.
Submitted On 10-NOV-2000
vempatee Well it should provide some workaround. on Multi-user systesm you can always check the id of the user who
is performing the operation and the file permission. If its not clear to specify the write option then there is
no meaning in providing the "setReadOnly" option with File object !!
Surya.
Submitted On 22-FEB-2001
renski You can delete a read-only file in Win95. Haven't tried
any other OS yet. But if you read the JavaDoc for
File.setReadOnly() it says: "Whether or not a read-only
file or directory may be deleted depends upon the
underlying system." I think it would be helpful to provide
some way to make a file writeable again, even the "remove
all write access" that mthornton suggested.
Submitted On 16-APR-2001
capmember1 This should definitely be added for 1.4 . If the operation
fails so be it. The argument about Multi-user systems is
spurious, because there IS a way to set the read-only flag.
Clearing it should be the reverse of this operation.
Submitted On 10-OCT-2001
jshowlett Removing all write access is a relatively safe operation.
Granting all write access is not, especially on UNIX
systems where it is the norm for writable files to grant
write access only to the file's owning user and group. Any
setReadOnly(false) method that fails to allow control of
this subtlety would be a Bad Thing. You're better off just
rolling your own until appropriate abstractions for file
permissons are provided.
That said, one reasonable implementation on UNIX might
be "set the file permissions to whatever the current umask
would create for a new file". You wouldn't want to name
this setReadOnly(false), but perhaps something like
resetDefaultPermissions().
Submitted On 06-MAY-2002
gtf3 Our application needs a way to get the read/write status of
a file, make the file writeable, do sometihng to the file,
and then change the read/write status back to the original
status. There need to be "boolean getReadOnly()" and "void
setReadOnly(boolean)" methods for this. BTW I note that
this bug was submitted in 1998(!!) yet still not fixed in
2002(!!!) Come on, guys, this is pretty basic functionality.
Submitted On 01-AUG-2002
wbrown I fail to see a problem with simply trapping an exception if the
underlying OS forbids the change due to it's security. Why
can't Java just delegate a call to the OS on this, regardless of
multiuser or not? I would suggest that currently the context
would simply be "current user". The OS would then decide if
the current user could toggle the flag.
This is very basic functionallity indeed.
Submitted On 02-AUG-2002
tibistibi if(! file.canWrite()){
//work arround for read only files
try{
log("Because file is not writable i will try to delete it and
remake it. File: "+file.getCanonicalFile());
if(file.delete()){
if(file.createNewFile()){
log("File is remade.");
}else{
log("Could delete the file but not remake it.");
}
}else{
log("Could not delete the file.");
}
}catch(IOException ioe){
ioe.printStackTrace();
}
}
Submitted On 05-SEP-2002
bestsss I see no reason why I can not set writting permision to a
file that I own. At least user permission. This is insane.
Sure, it is not enough but is far better than now.
However current situation w/ setting read only is complete
bullshit. It makes no way to undo the operation.
Submitted On 12-SEP-2002
SWP As in the other comments, the question of "writable by whom?" is a silly argument.. writable by the current user (i.e. this Java process) would be infinitely better than having nothing, and is quite likely all that is ever required. Most often the user running the java code wants to make the file writable because that user wants to overwrite it. This is a simple problem. The evaluator is making it unnecessarily complicated.
How can this have gone on for 4 years already? This is embarassing for Sun.
A future API that has proper access to ALL file attributes (the API that should have been there from the beginning) can handle the more complex issues.
Submitted On 12-SEP-2002
SWP This issue just came up because a friend noticed that the popular program InstallAnywhere was unable to install files over a previous installation (on Windows) because the files had been copied from a CD and Windows had therefore marked them as read only, because that is what they were when they were on the read-only CD medium.
InstallAnywhere is mostly great but it is effectively broken because of this BUG (things this stupid aren't RFE's in my opinion :-) ).
Submitted On 04-FEB-2003
marcjohnen1 After five years this seriously sucks!
Submitted On 26-FEB-2003
Nubbs Actually the evaluation gives the hint how setWriteable()
could be implemented:
Set the file permissions to match with what would happen if
the read-only file was deleted and rewritten.
The benefit would be that the overhead rewriting the file (->
reading it fully and writing it again) could be omitted.
Just like some comments already say: Something (like this?)
would still be better than nothing.
Submitted On 13-NOV-2003
okidoky I think the permissions on modifying a file to become
writable should become equal to whatever permissions a new
file would have had. I think that would be reasonable and
logical.
Submitted On 29-JAN-2004
bernie01 Just a warning. If I use under Windows the DOS command
ATTRIB with Runtime.getRuntime().exec(command) , then the
error e.g. "Sharing violation reading drive C Abort, Retry,
Fail?" cannot be caught because it locks up the Java
application while the error message requires the user to
type a reply into the DOS window. The DOS window is hidden
at the bottom of the window list so there is little chance
that the user sees it.
Submitted On 02-FEB-2005
cowwoc I agree with SWP. The "writable by whom?" question is irrelevant. Whom is the user associated with the Java process.
Gili
Submitted On 11-APR-2005
pc_matzke >After five years this seriously sucks!
And after seven years.. I don't know what to say.
PLEASE NOTE: JDK6 is formerly known as Project Mustang | 
