My colleague has replicated this, whenever we attempt to use MP3tag to edit the tags on our podcast, it consistently just deletes the file. This happens very frequently and if we had not the orignial working files
This is a great programme, but we have to ditch it if this issue can't be resolved. The only influencing factor is that it seems more likely to happen when the folder is the local version of a Google Drive folder.
I don't know if this is a solution: don't store it in a location that has the slowest possible access time.
What I think it is:
When updating the tag data, another nosy program tries to read this information (could it be that WMP or some other program has this network folder as watched location?) and opens the file while MP3tag tries to write it. This leads to blocking the file and the modification cannot be transferred from a possible temporary file to the target file.
And as any modification could require to copy the whole file to a local folder and then back again to the network location, it causes a lot of (slow) network traffic. A workflow where the files for modification are stored locally during the editing and then transferred to the target location, would definitely speed up the process and save on the online budget.
Another favourite: insufficient access rights like not being the owner of the target folder or the folder is not open to "everyone".
WMP is not installed, and it's not a 'watched location' for any other program, but of course changes in the various files in this folder are replicated to the cloud; this is also the case with anything in a Dropbox or OneDrive folder, which is pretty much all working file folders on Windows computers these days.
Since the file being worked on is in a local folder where we have full rights I don't think this applies. It's a SSD drive on my end, my colleague has replicated this on his local C HDD.
Does the synchronizing process with the network location run at the same time?
Have you checked the access rights and ownership of the folders in question or do you only think they are OK? This forum has a number of threads that deal with problems while writing files and in many cases the access rights where not set properly.
As I do not use cloud storage I cannot reproduce your problem.
This is a very common process. When a file changes, it is replicated to the cloud, so it is a background process running all the time. I save files from pretty much all the programs that I use in these folders, no issues with any other program.
This is the file folders of my C drive. I have rights to read, write, edit and delete. Is there something more that I might need?
I bet that you can set how often or in which intervals such a synchronization is performed. So what about switching it off while you edit? Just as a try.
Or edit in a folder that is not part of the cloud service and then copy the files to that cloud service target.
This would rule out that actually MP3tag does what you claim it does: delete files.
I still suspect that you have conflicting processes that hinder each other's functions. If that is the case, I would separate them.
In respect to access rights: you have the least trouble if you actually own the folder(s). Esp. older installation that got migrated from one Windows version to the next might still carry the attributes of the old owner. Just to make sure that this is no source for trouble.
I had contact with William via private email and we confirmed that Google Drive Sync was locking the file. Mp3tag uses a temporary file for writing tags if the new tag doesn't fit to the existing reserved space in the file and the file exceeds a certain size.
While trying to rename the temporary file to the actual filename, the locking process didn't allow this operation to succeed leaving the temporary file.
I've now implemented a fix where the original file is in no case deleted. In case the original file is locked by another process, it still produces an error message but doesn't make any modifications to the file.
You can test the new implementation with the latest Development Build Mp3tag v2.83f.
Does this mean that the threads that reported blocked files (or that files could not be opened for writing) that had other blocking programs as cause (and not insufficient access rights) will now be a thing of the past?
No. Mp3tag can't unlock files that are locked by another process. But I've implemented a timeout mechanism where Mp3tag retries moving a file in case of a sharing violation. Could be that the reports are less frequent now