United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4939819 File.canWrite() returns false for the "My Documents" directory (win)
JDK-4939819 : File.canWrite() returns false for the "My Documents" directory (win)

Details
Type:
Bug
Submit Date:
2003-10-17
Status:
Closed
Updated Date:
2013-07-19
Project Name:
JDK
Resolved Date:
2011-05-18
Component:
core-libs
OS:
windows_vista,windows_2008,windows_xp
Sub-Component:
java.io
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2,6u10,6u16
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
Name: rmT116609			Date: 10/17/2003


FULL PRODUCT VERSION :
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)

FULL OS VERSION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
File.canWrite() returns false for the user's "My Documents" directory, when specified as the path "c:\documents and settings\<username>\my documents".

This is incorrect as the "My Documents" directory is writable.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the test program below.  When the Swing file chooser appears, navigate to your "My Documents" directory via
c:\documents and settings\<your username>\my documents
Click OK.  The debug output will indicate that this directory is not writable.
Some subdirectories under "My Documents" are writable - here's some sample output:
$ javac Foo.java && java Foo
** Not writable **: C:\Documents and Settings\johnc\My Documents
Writable: C:\Documents and Settings\johnc\My Documents\Visual Studio Projects
Writable: H:
Note, this is not a Swing problem, as the same happens when creating a File object for "c:\documents and settings\johnc\my documents" and calling canWrite() on that.



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
canWrite() should return true for the "My Documents" directory.
ACTUAL -
canWrite() returns false for the "My Documents" directory.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
import javax.swing.filechooser.*;
import java.awt.*;
import java.io.File;

public class Foo extends JFrame {
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        JFileChooser chooser = new JFileChooser();
        chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
        chooser.setFileHidingEnabled(false);

        while (true) {
            int option = chooser.showDialog(frame, "OK");
            if (option != JFileChooser.APPROVE_OPTION)
                continue;

            File file = chooser.getSelectedFile();

//         try {
//             file = file.getAbsoluteFile();
//             file = file.getCanonicalFile();
//         } catch (Exception e) { System.out.println("e"); }

            if (file.canWrite()) {
                System.out.println("Writable: "+file);
            } else {
                System.out.println("** Not writable **: "+file);
            }
            chooser.setCurrentDirectory(file);
        }
    }
}

---------- END SOURCE ----------
(Incident Review ID: 216229) 
======================================================================

                                    

Comments
EVALUATION

Will investigate after build 30.
###@###.### 2003-11-18
                                     
2003-11-18
WORK AROUND

Make the dierctory writable by toggle the readonly attribute (eg: attrib -r C:\"Documents and Settings"\Alice\"My Documents")
                                     
2006-03-08
EVALUATION

--

If you right-click on C:\Documents and Setting\Alice\My Documents and examine the properties you will see that the Read-only attribute bit is set. The java.io.File canWrite method tests for write access using the Windows _waccess function and indicates that write permission is not allowed. At this time java.io.File does not understand  special shell folders and the only workaround is to toggle the readonly bit and make the directory writable.
                                     
2006-03-08
JUSTIFICATION

Priority changed from [4-Low] to [3-Medium]
Fix needed for Swing's JFileChooser.
###@###.### 2006-04-25 18:10:59 GMT
                                     
2006-04-25
EVALUATION

On my XP system, right-clicking on ANY folder and showing properties shows the folder as being read-only. But only "My Documents" disallows writing. The attrib command shows the R flag for "My Documents" but not for other folders.
                                     
2006-04-25
Votes are up to 16 on our Swing bug. I'm increasing the priority - this affects Swing.
                                     
2006-04-25
Mail thread between Swing (Shannon Hickey) and io on the subject:

Hi Alan,

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?

Thanks!
Shannon

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
>> otherwise."
>>
>> 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,
>> etc).
>
>
>
> 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.
>
> -Alan.
                                     
2006-10-31



Hardware and Software, Engineered to Work Together