Given a NT file with "Full Permissions" set to "Everybody".

the file:
File usagers = new File("d:\\java\\httpserver\\outbox.tmp");
...
System.out.println(usagers.canWrite());
System.out.println(usagers.delete());

The output is:
true
false

and the file is not deleted.

If I set the permissions to "none" for "Everybody" and I run the 
same code, the output is:
true
true

and the file is deleted.

======================================================================
Posted Date : 2006-04-29 16:28:30.0

======================================================================

4/29/06: The implementation of canRead and canWrite date back to JDK1.0. They were implemented using the Win32 access/waccess function which simply checks that the file exists and does a simple check of the readonly attribute. It does not check the ACL and hence does not report the actual/effective access to the file. This is fixable for regular files but more complex for directories. Another aspect to this bug is that File's delete method returns a boolean and there isn't an exception to indicate the reason why it failed. As part of JSR-203 we will be providing a new file system API that will provide access to the security attributes. This will allow applications to determine the effective access to the file. Also, all operations on files will throw exceptions so that security/permission related failures will be clearly reported.
Posted Date : 2006-04-29 16:28:31.0

I am having the same problem deleting files on a NT 
system.  However, no matter what I change the permissions 
to I can't delete the files.   The same code works fine on 
Solaris.

Me three.  Same problem.  File.renameTo() returns false as 
well.

FIX Yes a real fix for this bug.
It is a common windows problem with file handles.  The 
problem I was having was when I opened a file from a 
method, and operated on it, then I used another method to 
delete the file.  Seems fine?  Nope.  
The problem lies in the Garbage collector:
I opened a file with:

sFilename = "/filename";
public method1(){
BufferedReader msg = new BufferedReader(new FileReader
(sFilename);  
// do stuff
// the fix begins
try {
 msg.close(); // close the ref!!!
} catch (IOException e){
 // report err
}
msg = null; // explicitly tell the GC to remove this
// end fix
} // end method one

method2(){
  java.io.File file = new java.io.File(sFilename);
  boolean isDeleted = file.delete();
  System.out.println(isDeleted);
}
With the fix code this works. producing:
>true
without explicit closing and nulling the object the link to the 
filesystem remains.  This prevents you from deleting the file.

I am having this problem on Windows2000
File file = new File("c:\\deleteme.txt");
System.err.println(file.delete());
produces:
false

I have 2 different Windows 2k systems at the exact same 
Service Pack level with the exact same JVM downloaded on 
the same date. The exact same directory structure for the 
applications that reside on the C: disk. The exact same 
application. The application does a sequence of operations 
that results in a sequence of writes of a <xxxx>.ser file and
then at the sequence it deletes the object that is the in 
memory image of the <xxxx>.ser file. The application then
attempts to rename the <xxxx>.ser file so that the object will 
not reappear with the next invocation of the application. 
It then tests to see if the file <xxxx>.ser still exists and if it
does it attempts to delete it.

On one system, it works as designed. On the other, <xxxx>.ser
will not delete.

On both systems though, when you re invoke the application
and work through a hack list of such files. The delete works
consistently.

Another vote for this bug fix. 

I also tried a work around recommended in another 
forum, which makes use of the randomAccessFile. The problem is that if you deny the read/write and 
execute file permitions on Windows 2000 and try to 
open it, the file is simply deleted. The issue is more 
critical than I thought. Must be fixed.

This bug has been around an awful long time, I just encountered it on Java 1.5.

File.canWrite() on a file which is not writeable is returning true.  How can this not have been fixed?

I wonder if NIO2 can offer a solution to this.  The new file attributes framework should make it possible to define a way to access the NTFS file attributes.

However it's worth noting that the current spec only defines subclasses for FAT and POSIX...

bug fix:

System.gc();
FileName.delete();