Java reporting incorrect directory permission under Windows XP?

[howachen]

For the following codes:
//---------------------------------
import java.io.File;

public class Test {

/**
* @param args
*/
public static void main(String[] args) {

File file = new File("c:\\temp");

System.out.println(file.canWrite());

}

}
//---------------------------------
It return true, even in the "security" tab, I removed all the users
(i.e. i can't click into the folder using the windows explorer)

why Java return true?

 

[John W. Kennedy]

For the following codes:
//---------------------------------
import java.io.File;

public class Test {

/**
* @param args
*/
public static void main(String[] args) {

File file = new File("c:\\temp");

System.out.println(file.canWrite());

}

}
//---------------------------------
It return true, even in the "security" tab, I removed all the users
(i.e. i can't click into the folder using the windows explorer)

why Java return true?

In Windows, marking a directory "read-only" means only that it cannot be
rmdir'd. Java canWrite==false on a directory means that you can't create
a file in the directory, which Windows won't stop you from doing.

Windows Explorer has its own set of rules, which the operating system
does not enforce, so they don't apply to programs in general, Java or
otherwise.

(In other words, in this, as in so many other areas, Windows is a big,
fat security hole.)

If you had a C program, it would tell you the same thing.

 

[howachen]

John W. Kennedy 寫é“：

For the following codes:
//---------------------------------
import java.io.File;

public class Test {

/**
* @param args
*/
public static void main(String[] args) {

File file = new File("c:\\temp");

System.out.println(file.canWrite());

}

}
//---------------------------------
It return true, even in the "security" tab, I removed all the users
(i.e. i can't click into the folder using the windows explorer)

why Java return true?

In Windows, marking a directory "read-only" means only that it cannot be
rmdir'd. Java canWrite==false on a directory means that you can't create
a file in the directory, which Windows won't stop you from doing.

Windows Explorer has its own set of rules, which the operating system
does not enforce, so they don't apply to programs in general, Java or
otherwise.

(In other words, in this, as in so many other areas, Windows is a big,
fat security hole.)

If you had a C program, it would tell you the same thing.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

well, i SUPPOSE Java is a cross-platform language, so the builder of
JVM should take care this, not the responbility of M$, isn't ?

anyway, on Windows XP, how can I tell if I really have the permission
to create new files insides a specific folder?

since canWrite didn't work as above...

thanks....

 

[howachen]

John W. Kennedy 寫é“：

For the following codes:
//---------------------------------
import java.io.File;

public class Test {

/**
* @param args
*/
public static void main(String[] args) {

File file = new File("c:\\temp");

System.out.println(file.canWrite());

}

}
//---------------------------------
It return true, even in the "security" tab, I removed all the users
(i.e. i can't click into the folder using the windows explorer)

why Java return true?

In Windows, marking a directory "read-only" means only that it cannot be
rmdir'd. Java canWrite==false on a directory means that you can't create
a file in the directory, which Windows won't stop you from doing.

in Windows XP (NTFS file system), when you remove all owners in the
security tab, it REALLY means you can't write to the directory, no just
can't rmdir'd

 

[Brandon McCombs]

John W. Kennedy 寫é“：

For the following codes:
//---------------------------------
import java.io.File;

public class Test {

/**
* @param args
*/
public static void main(String[] args) {

File file = new File("c:\\temp");

System.out.println(file.canWrite());

}

}
//---------------------------------
It return true, even in the "security" tab, I removed all the users
(i.e. i can't click into the folder using the windows explorer)

why Java return true?

In Windows, marking a directory "read-only" means only that it cannot be
rmdir'd. Java canWrite==false on a directory means that you can't create
a file in the directory, which Windows won't stop you from doing.

in Windows XP (NTFS file system), when you remove all owners in the
security tab, it REALLY means you can't write to the directory, no just
can't rmdir'd

If you are referring to what I think you are your terminology is a bit off.

The groups/users listed in the box on the Security tab are not owners
but just a list of groups/users who have varying levels of access to the
file/folder. You have to click on Advanced button on the Security tab
and click on the Owner tab (on the new popup dialog) in order to
actually see the list of owners and from what I've seen you can't have
more than 1 owner at a time for a folder/file but more than 1 *possible*
owner is listed that you can switch to.

 

[howachen]

Brandon McCombs 寫é“：

John W. Kennedy 寫é“：

(e-mail address removed) wrote:
For the following codes:
//---------------------------------
import java.io.File;

public class Test {

/**
* @param args
*/
public static void main(String[] args) {

File file = new File("c:\\temp");

System.out.println(file.canWrite());

}

}
//---------------------------------
It return true, even in the "security" tab, I removed all the users
(i.e. i can't click into the folder using the windows explorer)

why Java return true?
In Windows, marking a directory "read-only" means only that it cannot be
rmdir'd. Java canWrite==false on a directory means that you can't create
a file in the directory, which Windows won't stop you from doing.

in Windows XP (NTFS file system), when you remove all owners in the
security tab, it REALLY means you can't write to the directory, no just
can't rmdir'd

If you are referring to what I think you are your terminology is a bit off.

The groups/users listed in the box on the Security tab are not owners
but just a list of groups/users who have varying levels of access to the
file/folder. You have to click on Advanced button on the Security tab
and click on the Owner tab (on the new popup dialog) in order to
actually see the list of owners and from what I've seen you can't have
more than 1 owner at a time for a folder/file but more than 1 *possible*
owner is listed that you can switch to.

okay, get to the job...

the main point is:

1. I cannot create new file inside the folder when i removed all users
in the security tab

i.e. File file = new File("c:\\temp\\test.txt");
file.createNewFile(); // exception - permission denied

2. Java return true when calling
file.canWrite();

is this a contradiction?

thanks...

 

[John W. Kennedy]

John W. Kennedy 寫é“：

For the following codes:
//---------------------------------
import java.io.File;

public class Test {

/**
* @param args
*/
public static void main(String[] args) {

File file = new File("c:\\temp");

System.out.println(file.canWrite());

}

}
//---------------------------------
It return true, even in the "security" tab, I removed all the users
(i.e. i can't click into the folder using the windows explorer)

why Java return true?

In Windows, marking a directory "read-only" means only that it cannot be
rmdir'd. Java canWrite==false on a directory means that you can't create
a file in the directory, which Windows won't stop you from doing.

in Windows XP (NTFS file system), when you remove all owners in the
security tab, it REALLY means you can't write to the directory, no just
can't rmdir'd

Silly Java is depending on what Windows tells it (always a mistake),
using a Windows API that was documented as answering the question "can I
write in this directory?", but which in fact reports only on the old
ATTRIB bits. With NTFS you have to go and mess with another whole new
set of API's to get an answer to the question. Because it involves a
large design change, it's been tied up in Java Specification Request
#203, also known as "NIO.2". Unfortunately, this is targeted for Java
7.0, so it won't be fixed soon.