• Post Reply Bookmark Topic Watch Topic
  • New Topic

java.io.File's delete()!  RSS feed

 
John P Shananan
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
here is a peice of code which is a bit puzzling:

now the file parameter is a java.io.File and this code, which is supposed to move it to an archive directory and automatically delete this file, fails to delete it. Here is the archive method:



Any idea why the 0 byte is getting archived but not deleted? Has it got anything to do with archive method being synchronized? If yes, what is the best way to deal with this?

answers are highly appreciated.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Welcome to JavaRanch!

We have a strict policy on display names, which must be a real-sounding first and last name with a space between.

Please go here and fix your display name up, pronto. Thanks, pardner!
 
John P Shananan
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. Its updated now.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I assume you have looked at the output and are not seeing any stack traces, correct? What about this code:

If an IOException were thrown here, you would set delete to false, but would not get any useful output explaining what happened. I recommend you add a printStackTrace() in here like you have for other errors. Also, add some print statements in the vicinity of the delete statement, so you can learn more about whether it's been run at all:

This way we can get a better idea of what's happening here, and can better focus our inquiries.
 
John P Shananan
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim, Thanks for the reply.
I am sure that there are no exceptions when the program runs, coz i debugged it myself. I had a watch on the boolean variable and it was "true" at runtime.
The control flows to the if block and executes file.delete() but, the file is still there in the same directory. The method archive() is synchronized - does this make any difference? as in - it would release the lock on the io resource? the problem is that the same peice of code works with any other file which is not 0bytes. when i debugged it with a file which has content, the file gets deleted right after file.delete() gets executed!!
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Synchronisation locks and file locks are entirely separate. The former is a Java thing and the latter is an O/S thing (and, in theory, an O/S might not even have them).

If you are using Windows, be aware that there are timing issues galore with file operations. At least, there are in the Java and Windows versions I am using: 1.4.1 and XP. So, for example, trying to delete a file immediately after closing a stream on it may fail (or it may not).
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by John P Shananan:

The control flows to the if block and executes file.delete() but, the file is still there in the same directory.


Based just on the code here, this can never be true -- the variable "delete" is never set to any value besides "false".
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looks like the delete parameter can be true when it's first passed into the method.

John, one common reason delete may fail is if there's still some sort of InputStream / OutputStream or other class which has not been closed and is associated with the file. It looks like the BufferedInputStream is closed - did you also see that code exit in the debugger? And BufferedInputStream's close() method should call close() on the FileInputStream, althogh this fact is poorly documented (and it isn't necessarily true for all streams, unfortunately). It might be nice to close() the FileInputStream too, after closing the BufferedInputStream, just to be safe.

However a more likely problem is: what about other IO classes associated with this file, before this method was called? E.g. how was the file originally created? With a FileOutputStream? Did any other classes read or write to the file after that? Did all these classes get closed properly?

I've heard people talk about timing problems with close(), but I've usually been able to solve such problems by religiously calling close() on all classes associated with the file. The only exception was a distributed file system that was very badly overstressed, such that even calling ls took several seconds to print each line. (So I would hardly blame the JDK for any problems that filesystem had.) Maybe I've just been lucky. Try simply adding a delay as Peter suggests, to see if it fixes the problem. For testing purposes, wait several seconds, see if that makes a difference. Note that if it does work, it may just mean that whatever stream was not closed properly, it's now been garbage collected. So this doesn't really tell you whether or not there was another stream. If waiting works, then you may want to experiment to discover how much delay is really required. I would probably make a progressive delay, so that it doesn't delay at all the first time it tries to delete, but if that fails it retries several times, with longer delays each time, before finally timing out.
[ January 22, 2007: Message edited by: Jim Yingst ]
 
John P Shananan
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter, Ernest and Jim - Thanks a lot for the replies.
Jim, Before the file is passed to the archive method, a FileInputStream is wrapped over it and a Reader wraps the same stream. From the code, I can see that they didn't close this InputStream. I will try to close these streams and then see if the delete works. I will keep you guys posted with the results. If it doesn't work, I will try to do it as Steve suggested.

What still puzzles me is this - the delete goes fine for all files except 0byte files (no text)!!! why not a 0 byte file?!
 
Paul Clapham
Sheriff
Posts: 22374
42
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why are the empty files not deleted? We've been over that already: it's because something still has them open.

My guess: something elsewhere in the code opens an input stream to read from the file, but then something in the logic fails when there is no input and an exception is thrown. And since there is no finally clause forcing the input stream to be closed (the guess part), the stream stays open.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another thing to consider: what creates these 0-byte files? Is there a process somewhere that was going to write to it and then forgot? Is that process still open? Maybe closing that reader won't be enough; maybe there's still another class or process that you need to find. I say "process" because it's possible it's not even something in your Java code at all. Could be something else running on the machine. You need to look at who creates the file, and who uses it.
 
John P Shananan
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot for your replies. Appreciate it.
You guys were right about the FileStream not being closed part.
Before the file is sent to this archive method.

The above piece of code is excuted. Unfortunately, ppl who coded it, didn't take care of closing the reader. I tried a reader.close() right after the file is read and it worked. The 0byte file got deleted this time right after file.delete().

Jim, I believe you would agree with me when I would use this piece of code



instead of this:



All, Thanks once again, for pitching in with your replies - They have been of great help to me in resolving this problem.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!