0000726: Inconsistent behavior when changing read-only files - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000726	MMW v4	Properties/Auto-Tools	public	2003-09-21 17:43	2012-06-15 14:37

Reporter	rusty	Assigned To
Priority	low	Severity	tweak	Reproducibility	always
Status	feedback	Resolution	reopened

Summary	0000726: Inconsistent behavior when changing read-only files
Description	When modifying read only files, the behaviour in MM is inconsistent and can be confusing: 1) Auto-tag or Mass tag files --> Warning dialog with option to overide read-only setting. Choosing to overide the setting causes it to change to read/write (permanently) 2) Auto-rename or rename files --> No warning dialog: the file is renamed, and the attribute is set back to read-only
Tags	No tags attached.

Fixed in build

rusty 2003-09-23 20:43 administrator ~0002350	3) When initiating volume leveling for multiple read-only files (tested with OGG/MP3)-->Warning dialog with option to overide read-only setting, however, the dialog is missing the yes to all and no to all options present in 1) 4) Related to 3). If the user attempts to convert an OGG file _and_ level volume while doing so, then a file name title.ogg.xxxxxxxx is created in the same directory as the source file! Raising priority to immediate.

rusty 2003-09-24 16:23 administrator ~0002353	5) Another bug, related to 2) is that when the user attempts to auto-rename files to a length that > 64 character CD limit, the operation fails if the file is read-only.

jiri 2003-10-07 21:36 administrator ~0002497	Fixed in build 582. 1) Not fixed, isn't urgent and in my opinion is even more desirable the current way in many cases (e.g. for me). 2) I could add a message for this, but again, I don't see it as much important. 3 & 4) Fixed. 5) Couldn't reproduce, there's probably something else involved.

rusty 2003-10-09 02:26 administrator ~0002508	Tested in 582 and it's sufficiently fixed for 2.0.2. I'm leaving this open because there are still a couple of minor remaining issues. 1) I agree we don't need to fix it if this if we consistently follow this behaviour in the application. 2) Behaviour should be the same as 1) (i.e. warning + change to read/write) 3) Fixed (implementation is same as 1) 4) Fixed 5) Cannot reproduce So basically, the only item remaining is 2) and it's fairly low priority.