• Post Reply Bookmark Topic Watch Topic
  • New Topic

Problem deleting and renaming file

 
Lukas Casier
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I've got problems deleting a file and renaming a tempfile. The file just won't delete and as a consequence the tempfile won't change name. I've tried everything and been looking into it for a long time now. All the readers and writers are (in my opinion) properly closed before I try to delete or rename.
The code:

I've done deleting and renaming in other methods and I do exactly the same thing but in this method, it just doesn't work.
Also, the file isn't open. (not in use by Windows)
Any ideas?
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you absolutely certain no exception has been thrown? That would cause your code to skip past the close() method calls. Usually it's best to put those close() calls inside finally blaocks, to make sure they happen no matter what else goes wrong.
 
Lukas Casier
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've changed the code to this:

No exceptions are thrown.
File hasn't been deleted and tempfile still exists in the folder.
EDIT: tempfile has the proper lay-out and has been changed in the right way. Only deleting the file and renaming the tempfile just won't work....
 
Rishi Shah
Ranch Hand
Posts: 43
Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Closing the outer writer will close all underlying streams and writers as well, so you only need to do br/bw.close(), and there's no need for a DataInputStream at all. Also, always close your streams in a try-with-resources or a finally block (if not using Java 7). On that note, if you are using Java 7, use the new File IO API http://docs.oracle.com/javase/tutorial/essential/io/fileio.html



Other than that, the code should work fine.

Edit: I missed it until I saw the post below, but File#setWritable() is useless in this case.
 
Paul Clapham
Sheriff
Posts: 21862
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just a couple of shots in the dark:

(1) I don't understand what the purpose of line 40 is. What happens if you remove it?

(2) The delete() method returns a boolean value. What is it?

(3) There's a Files.delete(Path) method in Java 7 which throws an IOException if it fails to delete the file. Can you use that?
 
Lukas Casier
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
System.gc() did the trick. No idea why I had to run the garbage collector to clear up unused objects as I close them all, but it works now.
EDIT: in a response to previous post:
1) That was a solution I found on the Internet. Worked for some people so I decided to give a try (you never know). But completely useless.
2) The boolean was false (before the System.gc())
3) I'll try to remember that
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've heard that on some systems it's necessary to do Thread.sleep() a few milliseconds after the close() to give the filesystem time to finish closing the file. This seems fundamentally wrong to me - IMO close() should not return unless and until the file is closed, period. But give it a try and see if it helps. To be really sure, sleep() for several seconds, to see if it makes a difference:

If that doesn't work - are you sure the code is really executing? Put in some print statements before and after the delete() call. What's the return value from that method? And what are the return values from setWritable(true) and renameTo()?
 
Rishi Shah
Ranch Hand
Posts: 43
Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lukas Casier wrote:System.gc() did the trick. No idea why I had to run the garbage collector to clear up unused objects as I close them all, but it works now.


Calling System.gc() doesn't guarantee Garbage Collection at that instant; you shouldn't depend on it.

System.gc() call simply SUGGESTS that the VM do a garbage collection and it also does a FULL garbage collection (old and new generations in a multi-generational heap), then it can actually cause MORE cpu cycles to be consumed than necessary.
 
Lukas Casier
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
System.gc() call simply SUGGESTS that the VM do a garbage collection and it also does a FULL garbage collection (old and new generations in a multi-generational heap), then it can actually cause MORE cpu cycles to be consumed than necessary.

So you mean I should further look into it until I've found the real problem? It's working for now
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, never mind.

Although it might still be worthwhile to try sleep() instead of gc(). It may just be that gc() is just causing a delay, much like sleep() would.

I agree with the other points that setWritable() and the extra close() are useless. But I figure you can clean that stuff out after the problem is solved. Thread.sleep() and System.gc() should be useless too, here, but it's possible you need them anyway.
 
Rishi Shah
Ranch Hand
Posts: 43
Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lukas Casier wrote:
System.gc() call simply SUGGESTS that the VM do a garbage collection and it also does a FULL garbage collection (old and new generations in a multi-generational heap), then it can actually cause MORE cpu cycles to be consumed than necessary.


So you mean I should further look into it until I've found the real problem? It's working for now


So, you're just calling this method in your main method?
 
Lukas Casier
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rishi Shah wrote:
Lukas Casier wrote:
System.gc() call simply SUGGESTS that the VM do a garbage collection and it also does a FULL garbage collection (old and new generations in a multi-generational heap), then it can actually cause MORE cpu cycles to be consumed than necessary.


So you mean I should further look into it until I've found the real problem? It's working for now


So, you're just calling this method in your main method?


Nope, I'm calling this in my finally block just before the file.delete();
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, the gc() solution seems unsatisfactory for the reasons Rishi gave. If it's possible to understand the real problem, that would be nice.

Another possibility is that there was some other IO object that didn't get closed, that was keeping the file open. Calling gc() may be causing that object to finally get closed as it should have been in the first place. This assumes that you might have been doing something else with the file earlier, in code not show here.
 
Lukas Casier
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guess what ...
System.gc() doesn't work anymore. I think it's weird. Tried thread.sleep(..) but that doesn't work either.
I'll check my other methods closely now for any manipulation of the file 'test'.
EDIT: found that fstream wasn't closed in a method that is being called right before markasRead. Have been searching for so long and i'm always careful to close the resources after use. Really stupid mistake.
Everything seems to be working fine now (tested 3 times).
Thank you very much . Happy I finally found my mistake.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Glad to hear it worked out.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!