What about "File Cannot Be Opened For Writing"?
Are file attributes set to "Read Only"?
I encounter this issue from time to time, but it usually occurs on a single file when running through a bunch of batch actions. My situation is likely attributable to the scenario ohrenkino listed above. On my end, I consider it a non-issue chalked up to Win7's indexer and preview generator. However, I never encountered an entire directory being read only unless I specifically changed the file attributes or it somehow resides on a corrupted sector(s) of my HDD.
Better to check the file and directory attributes and/or run CHKDSK /F DriveLetter or CHKDSK /R DriveLetter. The former CHKDSK fixes corrupted files and the latter scans and locates any bad sectors. Maybe you should include /X flag to dismount the drive when checking for bad sectors.
my turn to trip over this very old chestnut with an archived folder with flac files (not read only, and the music played fine).
Tried without success:
- take ownership of folder, files
- select files from within mp3tag rather than context menu
Then used foobar to convert flac to flac and that worked, so can now adjust tags etc.
That seems to be my issue too, though my files are standard mp3, exported from premiere. The files have had tags, (and still do), but they do nt show up under the install of the app on windows 10. When I tried to recreate them in one of the files I get the 'cannot open for writing' error.
Is it just a windows 10 thing? The file is not marked 'read only' in properties.
There are so many steps described in the thread including links to other threads.
Which of the steps have you performed and what was the outcome?
I'm also having this same issue. However, it's only from a certain way of trying. Everything works fine when editing files from my PC or a NAS Hard Drive, but when using an IDE Laptop Hard Drive in a USB Enclosure, neither the File Names (in the Filename listings area) or the MP3 Tags can be edited via with MP3Tag. I get the error "File xxx cannot be opened for writing." I can access the files just fine with File Explorer (Windows 10), and edit the title names, etc., but MP3Tag can't work with them.
These are the same MP3s that are on the NAS, just copies of them on the USD Hard Drive. They are not copy protected or set to read only. So, since it doesn't seem to be a problem with the MP3Tag v2.82 program itself, I'm wondering if you have any suggestions for me. I haven't seen anyone post this kind of specific detail, but maybe this was their problem as well.
Thanks in advance,
Just to get into the right direction: MP3tag only reports that what the OS reports back.
So you have to check what happens in your OS environment.
And if the file cannot be opened for writing then another process/program blocks it (if you have ruled out all the other problems coming along with insufficient access rights).
So: what other programs (including Windows Explorer) access the files at the same time?
Close these and what happens then?
I'll look into this more closely today, but I need a little more help.
I don't know what this means.
Can Access Rights get changed in the process of copying files to a USB Hard Drive?
I'm not sure how to change them myself, if they need to be adjusted.
As far as I know, the only programs that had those particular MP3s open were MP3Tag and Windows 10's File Explorer. Like I said, I've used MP3Tag successfully with the same files on my PC and my NAS. But this is where I'll start today, working only with the USB Hard Drive, and I'll report back.
In the meantime, if you could address my comments to what you said that is highlighted in red, I'd appreciate it.
Then I looked into Permissions and found something to try. I set the permissions on the entire USB Hard Drive to Full under my User. It was already set to Full under Administrator, but the changes to Read-only and to my User Permissions seems to have fixed the problem.
This made me take a look at the NAS and I found that some of the files were set to Read-only, so I'm changing them all. Then I'll have a look at Permissions there as well. I guess this should prevent future copies from having issues.
Guess I'll have to look at the PC after that.
Thanks for working with us!
Apparently, you have found a number of issues in your OS environment in respect to ownership and read-only flags.
You remedy these issues with the OS utilities - so this did not have to do anything with MP3tag. MP3tag was only the messenger: it reported that files could not be opened for writing (for whatever reason).
As the previous posts addressed write protection and access rights (it is generally not enough to be admin on a machine, you have to be the owner or access rights have to be set in such a way that "everyone" has full rights - which you might not want) I added the possibility of temporarily blocking programs (whereas the OS stuff usually leads to a permanent block).
But all these circumstances can only be seen locally - and you checked locally, so everything is fine now, I think.
I've checked all music files everywhere for Read-only and Permissions, and tested many of the files in MP3Tag. I think all is well now.
Thanks for making me think about everything that could have been an issue!
HI All ,
I also had this issue and yes it was driving me nuts .......................
By good luck I found out the culprit in my case was image files in the wrong format
Just an FYI. In Win 10 I had the same issue with some m4b files and found that they were being synced to OneDrive (Don't remember setting that up). You can tell by the status column in Explorer.
I had the same problem tagging my MP3 files. I tried everything, including trying to remove read only status for files/directories...didn't work; couldn't remove. Then I remembered I had a similar problem with other files.
The culprit for me was the windows 10 Windows Security. Under Virus & threat protection I have Ransomware Protection turned on. This is what kept me from updating tags. The solution is to add MP3tag.exe to the exception list under "Manage ransomware protection". Now everything works great.
Just thought this might help other who have tag writing issues in Windows 10.
I came across this thread after I encountered a similar problem with a single WAV file. I want to share my experience because in this case I believe the problem didn't have anything to do with Windows security, permissions, etc., but with the integrity of the file.
I was tagging my WAV files collection. After having done over 2000 files successfully with Mp3tag (what a great tool it is!), I came across one WAV file which kept getting the message "File Cannot Be Opened for Writing". The rest of the files in the same folder did not get this message and were tagged just fine.
The problematic file played fine in foobar2000 and could be copied to other disks without any problem (the issue wasn't disk corruption then). When checking its integrity, foobar2000 did not report any problems. However, trying to tag it in Mp3tag always resulted in the same error message.
After trying various things (like resorting to a backup copy of the same file, etc.), I tried something similar to what someone described above: I compressed the file to FLAC and then decompressed it. This time Mp3tag created a tag for it (for the decompressed file) without any problems.
Now, when I compared the original WAV file and the one created after decompressing from FLAC, the EAC compare tool did not show any differences whatsoever. The foobar2000 Bit-compare tracks tool did not report any differences in decoded data, either. However, Duplicate Cleaner did not show the files to be identical.
No wonder, since when I checked their size, it turned out that the original file is 16 bytes longer than the one which emerged after compressing the original one to FLAC and decompressing it.
Taking all of the above into consideration, I believe the problematic file must have had some kind of glitch in its structure - the 16 additional bytes - beyond the actual audio data - which prevented Mp3tag from processing it correctly. FLAC-compressing and decompressing it resulted in the resolution of this problem - I hypothesize that it happened thanks to getting rid of the problematic extra chunk of the file.
If anyone encounters a similar problem with a WAV file, I would recommend trying the same (or similar) method - I think it should help.
See this thread on problematic wav files:
Well, I also experience the problem that the file could not be written... Read the entire thread, and played for quite some time checking rights and ownership.
And nothing worked.
Installed another MP3 tagger (Metatogger 6.0) and it has abolutely no problems with editting the tags.
Tried MP3tag after that again, and it still refuses any editing.
Conclusion, the program has a bug. Might be a diifcult one to fix, but it is broken. No excuses.
Other than that - the structure and interface looks great. Must have been a lot of work. Would be nice if that problem that so many are experiencing is looked into and fixed. The software deserves it.
To issue a bug report, I think that your post lacks a number of vital pieces of information.
What kind of files do you treat? MP3? Flac? Wav? Mp4?
Have you run the unwilling files through tools that check the integrity like linked here: How to check files for errors?
How do you know that the other tagger has made it better and not worse like e.g. simply stacked further tags on top of already existing but corrupt tags?
Are the files taggable if you move them to a different folder?
And what about other programs that access the files at the same time? have you made sure that there is none running and how did you do that?
And finally: if all these local checks still so not lead to a solution, it would be nice to get a sample file.
Thank you, ok, did some checks following your instructions, and indeed some of the MP3 files had issues, although they played fine. And when they show up in MP3tag, most of them showing tags just fine, it is for a casual user not obvious there is something wrong with the file. I suppose when the software reads the files to find the tags, it can already detect issues with integrity and it would be nice if they were labelled with a mark or shown in red. So that you know something is wrong with it. That would save a lot of time investigating if it has anything to do with ownership, rights, file locked by other processes, security settings, as is also suggested as possible causes in this long thread.
Perhaps it is also an idea to clean up the thread, rather than newcomers going through all the replies that point in wrong directions. Also, if the alert was a bit more informative than just mentioning that the file could not be written - that would be a good thing too. Now I understand that it is not that the program is not able to write the files back again, it is merely that you decide not to do so because of the risk of adding more crap to a file that is already somewhat damaged or lacking the proper structure. That is in itself an excellent approach, don't mess with a damaged file to avoid more problems. But give the casual user a bit of feedback why the command can not be executed. The warning that the file could not be written should only be displayed when the software already has build the new image, and gets an unsatisfying return value from fwrite() or whatever function is used to replace the file with the new one. If is not possible to build the new file image because the source image is corrupted, than put out a different warning.
Thank you for your reply and time.
I had a lot of tagging problems with old files sourced from various locations years ago (5 to 10 years). I have a feeling that some software used decades ago to rip audio were poorly written because it was generally very old files (audiobooks mostly). mp3Val was recommended to me and using it before tagging corrected 99% of the problem files. I had to go to extreme audio editing in Audacity for only a few. I recommend that little piece of software a simple first go-to for problem mp3 files providing they can be opened..