View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005290 | MMW v4 | Properties/Auto-Tools | public | 2009-02-09 19:06 | 2010-10-27 12:44 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 4.0 | ||||
| Summary | 0005290: Illegal characters explicitly entered for filenames aren't prevented | ||||
| Description | 1) If the user tries to change a filename (or directory) manually (e.g. in the Tracklist or Properties dialog) and includes illegal characters such as \ / : * ? " < > | , MediaMonkey does not prevent the user from making the change. The result is that after making the change, the user gets 2 different error dialogs about a) the filename already existing b) the filename can't be written. What should happen instead is that the dialog should prevent the illegal characters from being used in the first place. This can be done in a manner similar to how Windows does it. e.g. user tries to modify the filename --> error sound occurs and the illegal characters don't appear. Context help appears indicating 'A filename cannot contain any of the following characters: \ / : * ? " < > | ' 2) A problem similar to the above is that when the user enters a mask, he she is not prevented from entering illegal characters in the mask. We might want to prevent MM from accepting a mask (i.e. leave the button greyed out, and show the context error message from (1) when it is clicked) until the mask is valid. | ||||
| Additional Information | http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=3739 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1300 | ||||
|
|
This isn't so easy, since both in cases 1&2 user can enter full paths, often with : and \ or / characters. The path can also be an URL, in which case it can contain even more characters, including '?', etc. Due to all these problems, it seems to me that we could simply ignore this issue. |
|
|
I think that in the case when file cannot be created the error message dialog should be enhanced in order to indicate also: .... Possibly due to some illegal characters in the filename (\ / : * ? " < > | ') Just so that computer novices could realize this and find the reason without contacting eSupport. But this is rather low priority issue. |
|
|
For both cases 1 and 2 isn't it 'obvious' when a file is being written, and if it is a file, which portion of the path is the hierarchy and which is the filename? e.g. if path starts with / or // or x: MM can't MM assume that a file is being written? And if it is a file, then the last portion of the path prior to /, //, or :: is the filename and therefore illegal characters can be prevented? It doesn't make sense to start burning a CD if MM knows that portions of the path are illegal and will result in an error. |
|
|
Yes, I think that we could take approch like this: 1. Following chars: * ? " | ' should be auto-removed (replaced by char _) automatically (similarly like in case of masks) 2. Following chars: > < should be auto-removed only if aren't doubled (don't create a mask) 3. Following chars: / \ don't need to be removed (just directory level indicators) 4. Following char: : should be removed only if it is not drive specifier (isn't followed by \ char) Note that the items above should be applied only if the path is not URL path as Jiri indicated. Jiri, assign to me for implementation if you agree. |
|
|
Let's look into it as two separate cases: 1. Filename/full path change in Properties dialog (or in-place in Tracklist). Here applying any rules can be a little dangerous, due to all the possibilities with URLs, etc. So, I'd rather not do anything about it, at least not in MM 3.1. 2. Masks - they are probably always ordinary filenames and so: a. All instances of * ? " < > | can be removed (or mapped to '-'?). b. \ should always be preserved c. : should be preserved in case it's the second character in mask (e.g. c:\...) d. / should probably be preserved (and handled internally in MM as \). |
|
|
I've set this to 'urgent' because I don't think we should tackle it in 3.1. Re. case 1: I think we should fix it properly after we think it through. e.g. if filename is preceded by http: or ftp: then different naming rules should apply. Re. case 2: OK. |
|
|
Re. 1: Problem here is that I'm far from being sure that URLs are the only problem here. They could be detected by :// characters, since the prefix can be anything (https, mms, etc.), but I'm afraid that there are also other possibilities. Assigning to Ludek to handle case 2. after 3.1 release. |
|
|
Fixed in build 1300. |
|
|
Verified 1318 |
