I have had this come up rather often and is annoying and hoping someone can shed some light on it.
I do alot of photo editing and when iam done editing my tif files, i highlight them all and delete. All seems well except one file wont delete. It does not happen all the time and it can be one or 2 files, but generall one at a time that wont delete. It tells me when icome to delete it a 2nd itme that he file is in use and thats it.
I cannot delete it in windows explorer either. I have to shut down DO completly and reopen it and the file is now gone. If ido not do it right away and come to delete more files... i can end up with 2-3 files ther that wont go away until i completely restart DO. This seems to only happens when i highlight a lot of large files.
I use the free utility called unlocker to resolve this issue (link below). Granted, I'd rather see an internal Opus way of unlocking locked files, but this ain't bad as you can run it from within Opus via your context menu.
[quote="nudel"]Which columns are displayed in your lister? (Or is it in thumbnails mode?)
Is the viewer pane open?
Are the columns or thumbnails still being updated when you get the file-in-use error?[/quote]
Hi,
The thing is, I do not get a file in use error.. not the initial time i come to delete.... I delete everything, it does not give me any errors, yet one file will remain. I get the file in use the 2nd+ time i try to delete it.
I am in details mode... and it happens even if the description column for all files is populated. It is not something i can reproduce, it either happens or it does not.
Are you deleting to the recycle bin? The error message is delayed if you are, since the recycle bin code in Windows retries, waits and retries deleting the file for a while before giving up.
I've experienced this exact behavior before with folders, but not with files. It's a long shot, but read my two posts in this thread, and see if anything from my experience might apply to your situation.
I've experienced this exact behavior before with folders, but not with files. It's a long shot, but read my two posts in this thread, and see if anything from my experience might apply to your situation.[/quote]
Hi,
The indexer was already turned off. The only thing unique about this drive is that is an encrypted drive using a program called DriveCrypt. However, While the file remains... as soon as I close DO, the file is released and is automatically removed. I do not have to delete it again after. Also while the file remains, it only remains as a name and takes space, but the file is no longer accessible.
Nope, that was one of the first things I had tried. So far when the problem presents itself, the only way I have been able to resolve it is to close DO. Once the systray icon and everything is shut down, the file vanishes and I can simply reopen DO and all is well again.
Interesting... If you've got time, could you check if the same thing happens when using the local harddrive and/or with any real-time anti-virus monitoring disabled?
Does it only seem to happen with TIF files or with any filetype provided there are lots of large files?
If it only happens with DriveCrypt then I can try reproducing it with BestCrypt (similar program that I have installed) or try installing DC itself if I still can't reproduce it.
I'm having this exact problem with mostly Adobe AI files. It says that they are 'in use' (Bull) and will not ever let me delete them. If I completely kill/destroy/mame DOpus 8, Explorer deletes them poste haste!!
Windows XP Pro 32-bit SP2, Dual Xeon, 4GB ram, 4 EIDE HD - computer user for 20 years (developer, build my own computers) so I'm not some weekend idiot.
It appears to me that DOpus is blocking the file deletion all by its lonesome. I do have AV running - but what would be its affection towards particular files and not the vast majority otherwise? And why would Explorer succeed and DOpus fail in such circumstances. Time for a new update it seems.
My take is that DOpus is the app that is placing these files in use (for whatever reason). This should never be the case (or should be overriden by such commands). I will gladly offer more information to resolve this.