A solution to Cannot open file for writting

My system: Windows 7 sp1 32 bit, MP3tag 2.51, Flac files, files on ReadyNAS Pioneer Edition with latest software 4.2.20

I have this problem from time to time and nothing else worked for me such as:

  • making myself owner, if I was Not
  • running mp3tag as admin
  • only selecting directories to edit from within Mp3tag (Cntl-D)
  • Even moving that album dir down to PC and going through everything above.

This works for every case I encounter without doing ANY of the above.

The problem is the embedded coverart, the jpg I must have put in with another tool besides Mp3tag, or possibly downloaded those FLACs with pre-existing "trouble" cover art!

MP3tag cannot edit or delete tags for these files and therefore you cannot use it in this case.

  1. You MUST delete only the cover art, embedded jpg from each of the files in this album
  2. I tried with foobar, dbpower amps IDEdit, etc. and they say they deleted the cover art, but did not and when going back to MP3Tag, the cover art was still there and Mp3tag could still not do any editing of tags
  3. I finally went to my old Tag&Rename, selected all the files, right clicked and picked Edit Selected Files, and deleted the cover art from there - which it did perfectly!
  4. going back to MP3tag, the cover art was gone, I could edit any of the tags I wanted to and then I just added the external jpg file back into the tags of the files with MP3tag and it did so perfectly
  5. at this point all the files in this album is fully functional with MP3tag again!!!!

I'm sure Tag&Rename is NOT the only way to kill these bad embedded cover art files, but it does work for sure. I'm not ruling out that it was Tag&Rename that I may have used that did the corruption. I'll also note that Tag&Rename would allow me to edit the tags even before ripping out the embedded cover art, but I do not want to use it. It can't do anything I need compared to Mp3tag.

Hope this helps, been meaning to write this up as a payback for all the help I got here.


Did you check the standard and extended file attributes?
The file or directory is read-only. Applications can read the file but cannot write to it or delete it. In the case of a directory, applications cannot delete it.
The file or directory is hidden. It is not included in an ordinary directory listing.
The file or directory is part of, or is used exclusively by, the operating system.
The file is being used for temporary storage. File systems avoid writing data back to mass storage if sufficient cache memory is available, because often the application deletes the temporary file shortly after the handle is closed. In that case, the system can entirely avoid writing the data. Otherwise, the data will be written after the handle is closed.
The file or directory is compressed. For a file, this means that all of the data in the file is compressed. For a directory, this means that compression is the default for newly created files and subdirectories.
The data of the file is not immediately available. This attribute indicates that the file data has been physically moved to offline storage. This attribute is used by Remote Storage, the hierarchical storage management software. Applications should not arbitrarily change this attribute.
The file or directory is encrypted. For a file, this means that all data streams in the file are encrypted. For a directory, this means that encryption is the default for newly created files and subdirectories.

Be aware that also a jpg image can transport embedded possible virulent bad code.


Yes I did check those attributes and it was not the issue, sorry I forgot to include that.

Hm, please tell me, how you have managed to check all the other file attributes than the four standard ones (read only, archive, system, hidden)?


  1. the obvious right click on parent directory and then on at least on of the files in the directory. Under the advanced button. I can see the file is avail to be indexed, file is ready for Archiving, and files were not compressed or encrypted
  2. from dos prompt and using the ATTRIB command, only the A attribute is set.

Am I missing something?

Hi there.
I've the same problem.
I didn't check if with embedded jpg only, but several times mp3tag says it's impossible to write the edited tags.
And of course I've checked that files' attributes were ok.
I run mp3tag on two machines: one with Win7-64 and one with Win XP-32.
I have the problem just with Win7.

This is still an issue with MP3Tag. This is the only way I still know to fix this problem. As I state below I have about 60k files and I have had only a few files, less than 10, that this has happened to. I'm sure MP3Tag did not corrupt this, but it could not fix it. Only Tag&Rename was able to fix.


I was having the same problem consistently since I started using mp3tag. I think I may have just stumbled on a solution, so far it hasnt happened today once while editing 1000's of files. It may have to do with the shmedia.dll windows component that constantly opens and reads metadata from media files in which the system is currently involved. Its functions are almost always laggy and delayed while keep the file locked for a ridiculous length of time.

I used nirsoft's RegDllView utility to temporarily backup the registry entries for shmedia.dll while using mp3tag, then restoring them afterwards.

I also disabled foobar's monitoring of library folders, and manually update the library after doing tag edits. This may also help the locked/tmp file issue. But I think more importantly this fixed a problem where almost every edited file was readded to the library, overwriting the Date Added in playback statistics component.

Hope this helps