• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System All players
  • Severity Medium
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Rockbox
Opened by RichardNeill - 2006-09-04
Last edited by nicolas_p - 2007-07-04

FS#5939 - Long pathname (>255 chars) crashes

Rockbox version 2006-08-30:
Machine ipod nano (4 GB):

I tend to use excessively long filenames on my main computer - up to the 255 char maximum for ResierFS if appropriate. I copied this file onto the iPod nano:

- Trying to select it (from the file browser) causes the nano to instantly crash, with coloured video “static” on the screen.
- Trying to select it from the playlist causes it to simply be skipped.
Other files with shorter names are fine.

Renaming the file to:
fixed the problem, so it’s definitely the filename which caused it. [I double checked - the file md5sum was correct]

I didn’t do any tests to find the exact buffer size which is critical. However: 139 chars = OK; 233 chars = crash.

I hope that info is useful.

P.S. Rockbox is great. Thank you so much - oggs on an ipod at last!

Closed by  nicolas_p
2007-07-04 14:41
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Reopen if necessary

Project Manager

How long is the filename including the path?

The full path, (wrt the root of the sdc2 partition) is:


Yes - that’s rather long, but ReiserFS (on my desktop) allows 255 chars for each element of the path. When the nano is mounted, the desktop kernel has no trouble with the filename.

[For info, my music is filed thus:


where Album is not necessarily the name of the CD, but the most sane way to refer to the individual work concerned. For classical music, filing by artist is rather unhelpful!]

I can confirm some pretty erratic behavior on H120. I just created an identical path, and when I tried to play it, I was told “No file” in the WPS. Then I pressed stop and I was sent to the dir browser (as expected), but a short while later, the screen went blank (a press on PLAY will reset on Iriver in this state).

This is with current CVS build, dircache enabled, and all settings default (except I increased the dir buffer size and turned off all voice features) in case that might matter.

Filenames longer than 260 characters will not work (firmware/include/file.h:#define MAX_PATH 260). Is this a case of Linux allowing filenames out of spec, or is Rockbox not following it? Either way, it probably shouldn’t result in a crash.

That should be (full) paths longer than 260 characters, not filenames.
And Dircache disabled, not enabled.

MikeS commented on 2006-10-27 10:35

Any string (or data) with a forgein source should be bounds checked really.

from the FAT spec:
“The total path length of a long name cannot exceed 260 characters, including the trailing NUL.” (long filenames itself are limited to 255 characters)

While Rockbox shouldn’t crash on such filenames it is clearly out of specs.

has someone checked if the crash got fixed by  FS#5736 ?

It does seem fixed to me (with standard settings and a pathname consisting of only ASCII characters). However, I just managed to play a file with a path of 260 characters, which shouldn’t be possible. Unless I counted wrong, which I don’t think I did. I’ll have to try again.

I can however absolutely positively confirm that Linux is not following the FAT spec.

Edit: Strike that. The filename and path given by submitter still causes Rockbox to break (not crash), so Rockbox is probably not checking that the path fits in the buffer or something like that.

I, too, have experienced this problem with long file names. It seems that as soon as the file names scrolls in either the file list or WPS, it locks up my ipod video (running the latest daily build).

Some examples that cause problems:

echo “Music/Caravan/1971 - In the Land of Grey and Pink/05 - Nine Feet Underground Nigel Blows a Tune Love’s a Friend Make It 76 Dance of the Seven Paper Hankies Hold Grandad by the Nose Honest I Did! Disassociation 100% Proof.mp3” | wc -c

echo “Music/Red Sparowes/2006 - Every Red Heart Shines Toward the Red Sun/01 - The Great Leap Forward Poured Down Upon Us One Day Like a Mighty Storm, Suddenly and Furiously Blinding Our Senses..flac” | wc -c

and several others.

The freeze on long file name scroll should be fixed now, but the original bug report probably refers to another problem.

Just tested this and it seems to be working… is it still a problem?

petur commented on 2007-04-12 22:41

Can this report be closed?

Um… couldent you just rename the files. Would it matter all that much?


Available keyboard shortcuts


Task Details

Task Editing