Cannot be opened for writing - Yet again

I hunted in here for a previous discussion of this problem, and AFAIK the last discussion was in fall of 2013.

Under Win10...

I went up to the root directory "My Music" cleared the read-only flag, applied it and saw the contents (folders and files) go whizzing by. NTL I still have files that I can't write to. Everything in Permission has a check before Write. I should be able to change the tags, but I can't.

This isn't a flaw in MP3Tag, it's an OS problem, but surely somebody's figured out what's borken in the OS and come up with a solution or work-around short of passing files through Audacity, etc.

A common suggestion is to change the ownership of the offending file(s). BTDT and the results match other files I can modify.

Can you give some details on the type of files? Are common properties like length, bitrate, ... of these files displayed in Mp3tag's file list?

I use a batch file to reset the ownership and attributes.

{Root of Directory}:
CD {path to directory}
attrib -r -s -a *.mp3 /s {NOTE: I convert all to MP3. You can change the extension, or add multiple lines for multiple extensions}
attrib -r -s -a -h /s /d
takeown /r /d y /f {path}
icacls * /t /grant Everyone:F
pause

May I ask why you set the attributes in 2 steps?
Are you sure that the permission "Everyone Fullcontrol" is needed?
(If you are the only person accessing this PC this is not a problem. Otherwise you will expose your files to "Everyone").

I think the first command applies specifically to the files, while the second applies to directories/folders. I'm not an expert, and I copied the batch file from someone else.

And, yes, I am the only one who accesses these files. You can always change ownership to the computer owner or logged in user, I guess. You'd have to do more research on the exact command.

This problem is file type agnostic - .wav, mp3... whatever.

I've compared files I know I can alter with MP3tag with files I can't change. If there's a difference, I can't see it. The ownership matches, the permissions match, so something's still not right.

There's one misleading point in this mess. Folders remain marked "Read Only". That is, click the little box to disable Read Only, and it looks as though that's happened. Go back to the folder properties, and it's back to being marked "Read Only". It's a Windows oddity, but doesn't cause problems with the included files. I've forgotten exactly why it works that way, but it does. One more reason to wish lots of Windows stuff ran under Linux without counting on Wine, etc. Grrr...

Have you checked the MP3s for integrity?
(See here:

If you load the WAV files again into an audio editor and save them again - does this help?

I changed ownership to Everyone (via the Properties windows). No change. This makes no sense to me, period.

That is the way how the "inheritance" thing works in Windows. Every folder get his access rights from the parent folder. If you don't want that behaviour, you have to disable the inheritance first for such folders and subfolders and then set the access rights explicit.
You can find details here: https://www.tenforums.com/tutorials/88305-enable-disable-inherited-permissions-objects-windows.html
This is nothing that Mp3tag could change. It depends only on your OS settings.
And please don't use scripts like the one posted above blindly. It could damage your folders really bad and in worst case make them inaccessible at all.

This seems to indicate something other than file ownership is at the root of your problem. @ohrenkino suggested already to check the file integrity for these. Did you have any success there? Since you have identified the ones with issues, you should be able to focus the test on just a few of those to quickly rule this out. If you confirm integrity isn't the issue, perhaps you can share one or two of the offending files for others to try on their side.

Sigh... I did a side by side comparison of files in the same folder (I re-ripped the content), which, I think, rules out in heritance (which is from D:\ or the parent isn't the guilty party, ditto for d:\My Music\Bach\Brandenburg Concertos. The problem is at the file level because the old files are locked, but the re-ripped files aren't.

Ownership, all permissions (including the advanced permissions) all look the same. Somewhere there's a piece of magic I'm missing, but darned if I know where.

Is there a place here to u/l samples? All things being equal, I'd just as soon not leave even a small of my Disk open to anyone with the URL.

Agreed that working with some scripts can be a quick way to an ugly outcome. One typo and... PFFT! All gone bye-bye.

I think that you can attach files to a post.
But as you talk about classical music: could it be that the filenames are reeeealllly long? Does shortening help?
And: what was the result of the consistency check?

The files in question are intact. That is they play (with MusicBee) without a problem. Or, the files themselves are sound. (no pun intended, but I'll take the credit anyway).

The files I'm currently tinkering with aren't the only "no write" files. They're scattered throughout my music collection. To add to the frustration, at some point in the past I fixed the problem for files in another folder. That is, the problem's fixable. Unfortunately, I've lost the grimoire with the applicable magic spell. Grrr...

Unfortunately, I can't upload the .WAV I had in mind (and 64 MB is a trifle large). Converting to MP3 will, of course, make the output file alterable. Grrr... again

This is not what @ohrenkino suggested: How to check files for errors?

You can send me a private link to an upload to one of the cloud services (e.g., WeTransfer, iCloud, GDrive, ...)

Ah hah! The problem goes back to something I though MP3tag couldn't cope with: .WAV's

Every example I can find, and I found some more, is a .WAV. Actually the music isn't always classical, it's just how the sampling worked out.

I don't have anything against classical music - my observation was only that sometimes the use of the Tag-File name converter leads to really long file names which then lead to problems. If that is not the case, fine.
Now: what happens, if you load such a wav into an audio editor and save it straight away - does that help?

I reloaded Foobar2000 and immediately remembered why I uninstalled it. MusicBee has a learning curve that IMNSHO is exponential, in the wrong direction. Foobar2000's curve is... you're kidding me, right? This thing actually works?

In any case, checking integrity isn't obviously in Utilities. Cleverly hidden, may well be, but obvious? Nope.

Regarding passing a file through Audacity and exporting it, the new file can be read and written, of course. It's a new file, so why not?.

All I can think of is that somewhere back when steam-driven abacuses were in vogue, something got to the original file, and made a mess of it. But I know I've fixed the problem without wholesale replacement.

As stated in the post we've linked to. Regarding the file that doesn't work:


Edit: Thanks for the example file! I'll look into this and will post any findings.

I've analyzed the file and noticed that some of the RIFF chunks don't report valid sizes. This means that the file is malformed. I've also checked the file with foobar2000's integrity checker which reports

Warning: Malformed or truncated chunk found at 1046548524 bytes, claimed length 12544 bytes, truncated to 2554 bytes

And to answer my question from above:

No, those are not displayed — which is an early indication of a problem with the file.