Create a directory which contains one readonly mp3 file.
Start Mp3tag.
Paste the full path of the directory to the field "Verzeichnis" and hit Enter.
Right-click the mp3 file and select "Tag entfernen".
Result:
The file content is changed (tag is removed), the readonly attribute is removed.
Expected result:
Readonly files should not be simply changed without notifying the user. The intention of a readonly flag is to prevent an application from changing the file content. All other applciations that I know tell the user something like "File is readonly and cannot be overwritten". At least, the user should be asked if readonly files should really be overwritten.
I am not quite sure if this is connected:
(from the change log):
[2015-07-08] CHG: renaming files marked as read-only does not require removing of read-only flag
anymore.
Thanks ohrenkino for your reply. Before I submitted my issue, I searched for "readonly" or "Schreibschutz" using the search function on this website, and I found the "How to disable read-only warnings post". So I assumed that the current implementation behaves as it is wanted: overwrite a readonly file.
But is there a chance that Mp3tag behaves like other applications, which do not simply overwrite readonly files? This doesn't necessarily need to be the default behavior, an option somewhere might also be a good idea, so that every user can decide by himself which behavior he/she prefers.
As you saw in the "How to disable read-only warnings post", Mp3tag used to warn when attempting to edit a read-only file.
But that warning was removed, some time after v3.05, without any explanation in the change-log.
I think that is a bug, not intended behaviour, and will make a bug report.