on FILE attributes (badly need help)

hi, i need some help deleting a file, this is my sitaution:

i have a code capturing frames from an mpeg stream, the frames it captured (jpeg) are stored on one folder. I have to rename all these during a particular method using renameTo (File dest), it works well for most of the images (i don't know why not all) but that's ok, i can just delete those that were not renamed using delete (File f). however, it always happens that it cannot rename the last file on that folder, and it cannot be deleted too. I tried using canWrite () to see if I could actually manipulate the file, canWrite() returns true and therefore that means I could. However, if i check the attribute of the file manually (right clicking on it and looking at its attribute) nothing is checked, not even hidden, read only or archive while all the other files are marked archive.

How do I do this? can i change that file's attribute to archive? how else can i delete that file? please help. I really need this badly. thank you very much.

I would guess that your program is simply not closing that last file. Windows won't let you delete (and possibly rename) a file that's open for writing. Check your logic to make sure the file is being closed.

thanks. i'll try that, actually I'm not sure whether I'm closing the files because this is just what I do:

ImageIO.write(bi, "jpg", new File(directoryName + "\\frames\\img" + count + ".jpg"));

this is within a loop, therefore writing all the images repeatedly. so i don't know how to close the files, can you help me?

thanks.

Well, that ought to close the files.

Are the calls to "write" and the calls to renameTo() in the same thread? Is one in a GUI event handler, and one in main(), for example? It may be that the writes simply haven't completed by the time you try to rename the files.

Assuming they're in the same thread, you might try inserting

after the write, before the rename. Just as an experiment. It seems that some filesystems allow Java IO methods to return before their effects have been fully completed. (In particulare, NFS filesystems under heavy network load can be untrustworthy.) Hopefully this is not the case for you; I really despise such filesystems. But if the sleep() makes a difference in your code, you may have to deal with it. One possible solution is to put the renameTo() in a loop - if it fails, wait n milliseconds and try again. You'll also want to specify a maximum timeout, after which you just give up - throw an error or something.

its like this:

class process implements Effect {
public int process (Buffer input, Buffer output) {
//this is where the write is also the loop
}
....
public void close() {
/*this is where the call to the class which performs the renaming. that class is in a separate file only made public*/
}
}
what do you think of this? is this why the renaming starts even if the write hasn't been finished? thanks. i'll try the code you gave me using sleep. i hope it works. thanks.

I don't think we can tell enough from your code. What code calls process()? What calls close()? Are there multiple threads involved?

um, the class gui calls the class process, where when you click open in the menu bar, function openFile will perform class. close actually is runs automatically i did not have to call it (it's kinda weird actually). i actually just reasoned out that maybe because class process is an implementation of Effects methods (can you think of another reason why this happens?). it belongs to the same class (class process) as the method process which it follows. I'm really sorry, I'm not good with threads, I don't know which is one, but guessing from what i know of now, I don't think there are threads, and i must inform you that the thread.sleep code did not work. is there any other way? thank you very much.

close actually is runs automatically i did not have to call it (it's kinda weird actually).

Well, this is suspicious. If we don't know how or why it's being called, how can we know for sure that it's called after the ImageIO.write() has completed? Try putting this into your close() method:

This will (hopefully) give you a stack trace which you can analyze to determine what code (if any) is calling your close() method. That may help you figure out what's really going on.

thanks. you've all been very great in helping me!