I maintain that old inherited software that uses basically zip files with a custom file extension to load and save “learning situations” – usually two sqlite databases and sometimes an image file.
The old software used a zip module I think written or adapted by Thomas Tempelmann, and this was slowly falling apart due to folder item and system changes. So I replaced that with Einhugur ZipArchive. What looked like an easy modernization has now revealed a lot of issues on Windows. When overwriting a save, I was renaming the folder item of the old zip file until the new one was written, deleted the first and renamed the second. All no problems.
Under Windows, the errors were hidden. Renaming did not work but caused neither error nor exception, and when I try different approaches best result so far is Windows showing a notification that the file cannot be overwritten as it is still opened by my app. Which is not true. The real working files are different from this zip and in a different location; only reference I hold is the temporary folderitem I need to handle it.
Any ideas what could make Windows believe the folder item is opened with error 104? It has write access, it’s not locked.
Unfortunately not, but I was this morning in a similar situation. Broken user profile on a Windows Terminal Server. Could not do my reparation work as admin. No information from Windows Server 2012R2 whatsoever. I had the “feeling” it must be something still locking some files in the user profile, but I could not tell, as taken over the permission on the folder as admin only showed an empty screen which finally freezed. Rebooting(!) the server was the only way to get it fixed. Well, only 30 users I had to kick out :-(.
I am not sure if it is related but I noticed at least for files that can be “previewed” in the file explorer the actual preview will hold the file open and therefore disallow deletion or renaming. I know this was true with PDFs for a while as we had an issue here at work with it.
Is it possible the file is open in a different application preventing modification?
I’ve also seen Windows just randomly decide to keep a file open for no apparent reason. I used to use an app called Unlocker to track these down and free the file but I don’t know how well it functions on Windows 10.
Thanks all. Well, at least good to know I’m not alone.
No, I checked every place and cannot find any clue. The original author was a bit wild saving folderitems for references. I made sure they will only be saved as path strings.
For Windows, it seems to be a fact that because I open that zip file once, it is an open file. When I use “Save as” to save to another file, this works nicely and I can also do concurrent saves to this new location. Once I open that new save file, the same thing occurs.
That all used to work xplatform with that old zip code, but its checking for resource forks and similar things that do not exist anymore made it necessary to replace it. I don’t blame Einhugur; it seems to be a Windows things rather.
Your app must still have an open reference to the file. Holding a FolderItem reference won’t do it, it has to be something like a BinaryStream. Maybe if you nil-out all references to the zip class?
If it’s not your app then try using Microsoft’s Process Explorer tool to search (Ctrl+F) for the file name. It will list all processes that have the file open.