File permission error when writing tags to FAT partition

When applying tag info from Discogs to a set of m4a files on a thumb drive formatted as FAT32 mp3tag complains "you don't have permission to save the file ". Pressing OK to dismiss the error results in mp3tag updating the file (the write succeeds) and moving to the next file in the list. The same behavior is displayed for all the files in the directory. All are successfully update (although one has to dismiss all the "bogus" error popups).

Follow up: Subsequent to writing the tags to the files reloading the directory only shows some of the files with the updated tags but the Finder shows all files updated. Removing and reloading does not seem to find the tag info on some of the files.

Update: The tag write to the files on the FAT32 thumb drive succeed but apparently the status back from the write(s) is interpreted as a failure. Finder update lag made it look like the write was happening after dismissing the error popup. The write had already succeeded before that. My error. BTW this is running on a mac os Catalina 10.15.7.

Thanks for reporting this issue and your detailed description! This is very helpful. I think it's an issue related to sandboxing and I'll try to reproduce it locally.

I'll keep you posted!

You're welcome. In the short term the workaround is to write the updates to a HFS or APFS partition and then copy them to the thumb drive. A first world problem, for sure, but it will be nice to have it work. Thanks for letting me know you are taking a look at it.

1 Like

I've just released v1.0.4 which potentially fixes the issue. It would be great, if you could try this again with the new version.

FYI, I got another report and it seems that the issue is not yet fixed with v1.0.4.

I was out of town. Sorry for the delay. My quick test on Friday worked. I made a small change to a set of files on my thumb drive. Was able to write them without the previous errors. Maybe there are two issues?

No problem and happy that it's working now for you!

I'll investigate further, maybe there are two issues — getting there :sweat_smile:

Sad to say the problem showed up again on a different folder. Now the behavior is that the error shows up and can be dismissed (and repeats for each selected file). But now instead of working despite the changes are actually made. :-(. Oh well. At least the behavior changed a bit. You must be getting warm.

Thanks for the update! Are the changes also not visible when you reload the folder via File → Open...?

Right you are. They changes showed up after I reloaded the directory (across restart of mp3tag). The previous behavior showed the changes to the files after dismissing each error.

Just FYI, I've now filed this as bug with Apple (FB9047017) and try to find a workaround for this issue.

When you wrote that you submitted this as a bug to Apple I did the following:
Opened a pdf file in Preview, duplicated it, moved the copy to the thumb drive (File->Move) which worked, then I rotated the page and tried to save the resulting file. I received an error from that and when I dismissed the error I received another error telling me the device was locked along with a unhelpful suggestion on resolving the error (the suggestion was based on the bogus assumption that the file was write protected; it is not).
Since Preview could copy the file to the thumb drive but not rewrite it what does that tell you about the problem? I think you are correct. This is Apple's problem. I'm surprised they haven't caught this yet. Seems like it would impact many users. And since I'm seeing this on Catalina this bug has been around for some time (unless one of the recent patches caused it).
I'm including some screen caps of the behavior I saw with Preview in case they are useful.
Thanks for keeping me udpate.

Next to the bug report, I've also submitted a DTS tech support incident. Over the past days, I was in contact with an Apple engineer who confirmed, that there is a bug somewhere deep in the FAT32 implementation.

He suggested helpful ideas for possible workarounds, I rewrote parts of the file-replacement logic, and I think this issue is now fixed with Mp3tag for Mac v1.1.0.

Thank you for the update.
I have some time later and I will try the new release on my thumb drive and provide feedback. Even the best computer systems suppliers release software, sometimes important software, with insidious bugs such as the FAT32 problem you have encountered. It's annoying and can consume a disproportionate amount of time. Usually the runtime support or OS operations are the last place one looks for problems. FAT32 is not going away. I hope Apple can resolve this problem so others won't trip over it in the future. Fingers crossed! :slight_smile:

1 Like

The fix (or workaround) is allowing the writes to succeed. However the performance seems slow(er). Thanks for making this work. When I can I'll compare the write speed to another thumb drive and to my system SSD and see what I find.

1 Like

Here's an example of a file that can't be written. Perhaps it is corrupt?
wav file that won't accept tag updates

Have a look at this thread:

The file in the link does not show any information in bitrate or frequency.
I loaded the file into the Nero Wave Editor and saved it immediately as wav but a different name which led to values in bitrate and frequency and also showed tag data.
So I would assume that the wav file is corrupt and the refusal to write has nothing to do with permissions this time but finds its origin in the file structure.

Thanks very much for finding this report. Sounds a lot like the problem I'm having.

So the Mp3tag defect is that the error it reports is "inaccurate". It should indicate a possibly non-compliant or corrupted file. The files that cause this behavior were generated with Audacity. Files from the same "split" original wav file work fine. Just the last several are "corrupt". I'll regenerate them and see if the problem was caused by a defect in Audacity or something else I did (I don't remember touching these with any other software).