Rockbox

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.

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.

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.

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.
> + , ; = [ ]

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.

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.

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.

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.

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.

I honestly don't think backwards compatibility is a major issue in this case.

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.