22

I'm using Windows-7 with java 7 update 6 and found this weird (at least to me) behavior -
I have two files E:\delete1.txt and E:\delete2.txt both are read only files, when I try to delete file like following it gets deleted without any issues -

File file = new File("E:\\delete1.txt"); 
assertTrue(file.delete());

But when I delete file using nio API like following -

Path path = Paths.get("E:\\delete2.txt");
Files.delete(path);

It throws java.nio.file.AccessDeniedException.

Why different behavior for same operation with old and new nio API?

Premraj
  • 7,802
  • 8
  • 45
  • 66
  • and if you swap the files you are deleting around i.e `NIO` api deletes `delete1.txt` and old api `File` deletes `delete2.txt` what happens? – David Kroukamp Aug 27 '12 at 09:43
  • 2
    @MichaelBorgwardt Why weird? He is simply trying to delete a file (which happens to be read only) – assylias Aug 27 '12 at 09:52
  • @assylias: weird or not, it certainly is an edge case – Michael Borgwardt Aug 27 '12 at 09:57
  • @MichaelBorgwardt so are you saying it's OK to have inconsistent behavior for same functionality? .. if it is the case then nio is not a true replacement for File API and if it is inconsistent then out of two one implementation must be correct and other is wrong. – Premraj Aug 27 '12 at 10:17
  • It's not so much OK as it is *inevitable* unless there were an official API with rigidly defined behaviour that both implementations explicitly claim to implement, and that's not the case here. – Michael Borgwardt Aug 27 '12 at 10:28
  • From the spec of Files.delete: "On some operating systems it may not be possible to remove a file when it is open and in use by this Java virtual machine or other programs." Can somebody test this behaviour on another OS (I just have Windows here atm)? – joergl Aug 27 '12 at 10:29

2 Answers2

22

As discussed here - The issue is that java.io.File has many oddities, on Windows in particular. In this case it resets the file attributes before it deletes the file so this is why it does not fail as might be expected. It is behavior that dates back >10 years and so would be risky to change now. It has several other oddities like this, just one of the reason why it wasn't re-implemented to use the new API.

If we try to delete the file from command window then windows throws the same (Access denied) error but file gets deleted from explorer window. It appears the File#delete() has a wrong implementation and new Files#delete(Path) should be preferred instead.

Premraj
  • 7,802
  • 8
  • 45
  • 66
  • 4
    Could this be expanded to explain more specifically what `File#delete()` does wrong? – ZX9 Feb 26 '16 at 13:48
2

Why different behavior for same operation with old and new nio API?

Because exactly emulating the behaviour of the old API for similar operations was apparently not considered an important goal in the design of the new API. Given that the main goal of the nio filesystem API was to present a new API with some quite different underlying concepts and a lot of new capabilities, it seems pretty normal to me.

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720