Rockbox

Tasklist

FS#5794 - Bookmarks can't handle filenames with semicolons

Attached to Project: Rockbox
Opened by Ben Keroack (bk) - Friday, 11 August 2006, 02:20 GMT
Last edited by Steve Bavin (pondlife) - Friday, 18 April 2008, 05:33 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The bookmark system uses semicolons as field delimiters in the .bmark file. When filenames contain semicolons (which are legal in FAT32 AFAIK) any attempts to play bookmarks with them fail. An example filename would be "Track 01; The Beginning.mp3".

Bookmarks should be changed to be either line-delimited or to use a character such as forwardslash/backslash that cannot appear in valid filenames.
This task depends upon

Closed by  Steve Bavin (pondlife)
Friday, 18 April 2008, 05:33 GMT
Reason for closing:  Fixed
Comment by Dominik Riebeling (bluebrother) - Sunday, 19 November 2006, 18:40 GMT
After a quick look into the FAT spec I found out that the semicolon (ASCII 0x3b) isn't allowed for short filenames. For long filenames, characters with a code point greater than 127 are allowed (which doesn't apply to the semicolon) and a couple of additional special characters, but not the semicolon.

How did you manage to create semicolons in the filename? Windows should prevent doing so. In that way I think it's perfectly ok to fail on semicolons in filenames.
Comment by Ben Keroack (bk) - Sunday, 19 November 2006, 19:33 GMT
Linux is perfectly happy creating filenames containing ';' on FAT32 filesystems. I don't have any Windows system to test it on however I think that a line-delimited bookmark spec is a clean solution to the problem.
Comment by Jonas Häggqvist (rasher) - Sunday, 19 November 2006, 23:05 GMT
Linux ignores the FAT32 specs in a lot of areas (illegal characters, filename/path length). This is a problem with Linux, and Rockbox is well within its rights to assume that filenames do not include semicolons. You could argue that it should perform a check on the filename before writing the bookmark, but that's pretty much it.
Comment by Jonas Häggqvist (rasher) - Sunday, 19 November 2006, 23:21 GMT
Actually, I take that back. The additional characters allowed for long names DO include the semicolon:

Page 29 of FAT32spec103.pdf:
> The following six special characters are now allowed in a long name. They are not legal in a short name.
> + , ; = [ ]
Comment by Dominik Riebeling (bluebrother) - Sunday, 19 November 2006, 23:43 GMT
Ah, you are right. I read the wrong line when stating about long filenames :( Sorry for the confusion.
(But Linux ignores the FAT specs still in a couple of cases). Why not using a tab character as delimiter in bookmark files? This should be safe for every filesystem possible.
Comment by Jonas Häggqvist (rasher) - Monday, 20 November 2006, 00:06 GMT
I guess there is a problem of backwards compatibility here. Some people might have a lot of bookmarks lying around, which will cease to work, but I don't see how that could be avoided, save for adding some sort of version marker to the new bookmarks, but that's rather ugly. I don't know how much of a problem breaking backwards old bookmarks is, to be honest. Maybe a plugin to convert old bookmarks to new ones could be written and included for a while.
Comment by Stephane Doyon (sdoyon) - Monday, 20 November 2006, 00:17 GMT
Re backwards compatibility: if TABs or some other char (perhaps \\) is
chosen as a new delimiter, encountering that char in a bookmark line
should be enough to conclude that the new format is being used, as old
entries can't include TABs or backslashes. If the new delimiter is not
found, then we could fallback to the old format with semicolon delimiters.
Comment by Magnus Holmgren (learman) - Thursday, 08 March 2007, 21:13 GMT
It is actually easy to reduce the problem a bit. It can be made so that only a ";" in a folder or playlist file name cause a problem, not in the name of the resumed file. On the other hand, completely changing the separator (in a backward compatible way, as suggested) isn't much harder.
Comment by Tom Ross (midgey34) - Friday, 03 August 2007, 04:51 GMT
Tested on r14152. When loading a bookmark for a song with a semi-colon in the filename, the bug still seems to occur. When the bookmark loads, the data seems to be loaded correctly. The WPS is updated to the right track and time and the playback status is changed to paused. Once the WPS is updated, the play status is changed to stopped and the user will be dropped to the main menu. Choosing 'Resume Playback' goes back to the WPS and plays the song from the bookmark in the correct location.
Comment by Linus Nielsen Feltzing (linusnielsen) - Tuesday, 01 April 2008, 07:22 GMT
I honestly don't think backwards compatibility is a major issue in this case.
Comment by Marc Guay (Marc_Guay) - Thursday, 17 April 2008, 21:08 GMT
I tested this recently and it worked fine for me (I guess some code was committed between then and now). But given the amount of time your average bookmark lasts, I doubt that backwards compatibility is a big deal and would vote to close this task.

Loading...