Mail thread between Swing (Shannon Hickey) and io on the subject:
Thanks for the discussion on this issue. I'd like to take a moment to explain why this is important for us.
As you know, the "My Documents" folder is the most common location for users to save files on Windows. It is also the default folder that comes up when one opens a Swing JFileChooser to save a file. As we have things right now, the "New Folder" button on our file chooser is enabled or disabled based on whether or not the folder being browsed is writable.
Since the method we call to determine this is busted, our button is busted. As such, users cannot create new folders in the most common place to create them. As you might imagine, asking all users to change the read-only attribute on "My Documents" for Java is not acceptable.
So we need a fix, or a better work around (in our code our File code).
One of the things I mentioned previously is that when I show properties for ANY folder on XP, the "Read Only" option is shown as checked. How come only "My Documents" is failing the canWrite() call?
It would be ideal to have this fixed in the File class, and I can't imagine how changing canWrite() to return the correct thing would break anyone. If this is absolutely impossible, then perhaps you can work with us to come up with an alternate solution for Mustang?
Alan Bateman wrote:
> Leif Samuelsson wrote:
>> The javadoc for File.canWrite() states : "Returns: true if and only
>> if the file system actually contains a file denoted by this abstract
>> pathname and the application is allowed to write to the file; false
>> It seems wrong for Java to only depend on _waccess for directories
>> when running on Windows, as it doesn't represent the real truth.
> The canRead/canWrite methods were implemented that way in JDK1.0
> and it's not clear if we should change the behaviour now. I would
> be wary of changing it this late in Mustang. I've cc'ed Iris - she's
> worked this area for a long time and might know if there have been
> any attempts to address this in the past.
> As you know the expected result (or the "real truth") is complex in
> that it's a combination of the effective permissions and the legacy
> FAT attributes. A volume might also be mounted readonly and that is
> important too (although this tends to get masked by the APIs). The
> expected result is also open to interpretation as there are
> inconsistencies in the interpretation of hidden attribute in
> Microsoft applications. One approach for regular files is that we
> just open the file with the required access. That will provide an
> accurate result for regular files. For directories we can do something
> similar for canRead but canWrite (and canExecute) are more complicated.
> In JSR-203 we should be able to do a lot better as we will have APIs
> to access and manipulate ACLs (that includes the ability to compute
> the effective permissions). We'll also have APIs to access other
> attributes. And of course we will know if a file system (or the
> underlying backing stores) are mounted readonly. Although this JSR
> is for Dolphin I mention it so that you know we have a plan to address
> this topic.
>> It seems to me that canWrite() on a folder/directory should return
>> a value based only on the security model (user access, mounted r/w,
> That would be the right solution but it's always been implemented using
> access/waccess and canWrite never checked if the file is a directory.
> As I said, I would be nervous about changing behaviour this late in the
> day. Instead I would prefer to re-examine the canXXX methods in Dolphin
> as we doing a lot of work in that area anyway with the JSR-203 implementation.