# Cannot be opened for writing - Yet again

**URL:** https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154
**Category:** Support
**Created:** [February 1, 2022, 2:21am UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154 "2022-02-01T02:21:35Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![RBEmerson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rbemerson/32/5040_2.png) [@RBEmerson](https://community.mp3tag.de/u/RBEmerson)
#### Post date: [February 1, 2022, 2:21am UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/1 "2022-02-01T02:21:35Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![RBEmerson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rbemerson/32/5040_2.png) [@RBEmerson](https://community.mp3tag.de/u/RBEmerson)
#### Post date: [February 1, 2022, 4:12am UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/2 "2022-02-01T04:12:26Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 1, 2022, 6:25am UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/3 "2022-02-01T06:25:14Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![jewahe](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/35a633/32.png) [@jewahe](https://community.mp3tag.de/u/jewahe)
#### Post date: [February 1, 2022, 6:39am UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/4 "2022-02-01T06:39:06Z")

</div>

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

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [February 1, 2022, 7:41am UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/5 "2022-02-01T07:41:56Z")

</div>

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").

---

<div class="post-metadata">

### Author: ![jewahe](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/35a633/32.png) [@jewahe](https://community.mp3tag.de/u/jewahe)
#### Post date: [February 1, 2022, 7:51am UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/6 "2022-02-01T07:51:55Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![RBEmerson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rbemerson/32/5040_2.png) [@RBEmerson](https://community.mp3tag.de/u/RBEmerson)
#### Post date: [February 1, 2022, 3:04pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/7 "2022-02-01T15:04:41Z")

</div>

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...

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 1, 2022, 3:13pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/8 "2022-02-01T15:13:32Z")

</div>

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

> [@How to check files for errors?](https://community.mp3tag.de/t/how-to-check-files-for-errors/44633):
>
> It’s required and often helps to reduce support cycles to check files for errors before filing a bug report. Symptoms of erroneous files are often missing or wrong bitrate or length audible blips or skips tags seem to be sticky and cannot be removed There are some really good tools to check the files for errors, namely MP3 Diags — identifies many different issues in MP3 files Website: [http://mp3diags.sourceforge.net](http://mp3diags.sourceforge.net) Download: [MP3 Diags - Getting MP3 Diags](http://mp3diags.sourceforge.net/010_getting_the_program.html#binWindows) If the font size in MP3 Diags is …

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

---

<div class="post-metadata">

### Author: ![RBEmerson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rbemerson/32/5040_2.png) [@RBEmerson](https://community.mp3tag.de/u/RBEmerson)
#### Post date: [February 1, 2022, 3:14pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/9 "2022-02-01T15:14:40Z")

</div>

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

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [February 1, 2022, 3:25pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/10 "2022-02-01T15:25:40Z")

</div>

> [@RBEmerson](#):
>
> 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".

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](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.

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [February 1, 2022, 3:29pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/11 "2022-02-01T15:29:45Z")

</div>

> [@RBEmerson](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![RBEmerson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rbemerson/32/5040_2.png) [@RBEmerson](https://community.mp3tag.de/u/RBEmerson)
#### Post date: [February 1, 2022, 4:36pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/12 "2022-02-01T16:36:25Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 1, 2022, 4:41pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/13 "2022-02-01T16:41:12Z")

</div>

> [@RBEmerson](#):
>
> Is there a place here to u/l samples?

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?

---

<div class="post-metadata">

### Author: ![RBEmerson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rbemerson/32/5040_2.png) [@RBEmerson](https://community.mp3tag.de/u/RBEmerson)
#### Post date: [February 1, 2022, 5:11pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/14 "2022-02-01T17:11:37Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 1, 2022, 5:24pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/15 "2022-02-01T17:24:05Z")

</div>

> [@RBEmerson](#):
>
> That is they play (with MusicBee) without a problem.

This is not what @ohrenkino suggested: [How to check files for errors?](https://community.mp3tag.de/t/how-to-check-files-for-errors/44633)

> [@RBEmerson](#):
>
> Unfortunately, I can't upload the .WAV

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

---

<div class="post-metadata">

### Author: ![RBEmerson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rbemerson/32/5040_2.png) [@RBEmerson](https://community.mp3tag.de/u/RBEmerson)
#### Post date: [February 1, 2022, 5:35pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/16 "2022-02-01T17:35:55Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [February 1, 2022, 5:39pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/17 "2022-02-01T17:39:18Z")

</div>

> [@RBEmerson](#):
>
> Actually the music isn't always classical

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?

---

<div class="post-metadata">

### Author: ![RBEmerson](https://community.mp3tag.de/user_avatar/community.mp3tag.de/rbemerson/32/5040_2.png) [@RBEmerson](https://community.mp3tag.de/u/RBEmerson)
#### Post date: [February 1, 2022, 6:39pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/18 "2022-02-01T18:39:28Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 1, 2022, 6:51pm UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/19 "2022-02-01T18:51:18Z")

</div>

> [@RBEmerson](#):
>
> In any case, checking integrity isn't obviously in Utilities.

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

> [@Florian](#):
>
> You can send me a private link to an upload to one of the cloud services (e.g., WeTransfer, iCloud, GDrive, ...)

* * *

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

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 2, 2022, 8:47am UTC](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154/20 "2022-02-02T08:47:56Z")

</div>

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](https://community.mp3tag.de/t/how-to-check-files-for-errors/44633) 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:

> [@Florian](#):
>
> Are common properties like length, bitrate, ... of these files displayed in Mp3tag's file list?

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

[Next page](https://community.mp3tag.de/t/cannot-be-opened-for-writing-yet-again/56154.md?page=2)
