OpenPandora Main OS

Quick Actions
Notice: Undefined index: tasklist_type in /srv/www/vhosts/ : eval()'d code on line 228 Notice: Undefined index: tasklist_type in /srv/www/vhosts/ : eval()'d code on line 233
  • Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category Core
  • Operating System Release 1 (Zaxxon)
  • Severity Low
  • Reported Version SuperZaxxon Final 1.53
Attached to Project: OpenPandora Main OS
Opened by Stephan Sokolow - 2012-09-16

FS#300 - SuperZaxxon interprets on-disk FAT32 filenames differently than desktop Linux


With SuperZaxxon Final, I've noticed that stuff running on the Pandora like Thunar and bash are seeing a different interpretation of filenames on disk than when I remove the SD card and insert it into my desktop PC. Specifically, the following two mismatches appear to be present when using a FAT32-formatted SD card: First, the Pandora's VFAT support seems to be be operating with different case-handling settings than desktop Linux distros. Filenames set in all uppercase are forced to all-lowercase on the Pandora (whether they're set on the desktop or the Pandora) but inserting the card into a PC reveals that the. All-lowercase filenames set by software on the Pandora risk appearing in all uppercase when the card is inserted into a PC. (I think the grsync PND is what created the files in question) Among other things, this forces me to use EITHER the PND-based copy of grsync over the network OR a desktop-based copy of rsync with an SD card reader but not both because the kernel will preserve case differences like ALBION.BAT vs. albion.bat but rsync think they are separate files. (resulting in Flash-killing, time-wasting deletion and re-creation) It also makes for irritating entries like "zzt" in DOSBox or "ddr" in PyDance where I can't capitalize the filename properly without employing Department of Redundancy Department with "DDR Songs" or "ZZT.The.Game" as an excuse for mixed case. Second, SuperZaxxon Final seems to be using a different (though still Unicode-capable) filename encoding than all the desktop distros I've tried. Filenames are preserved properly and all-ASCII filenames are displayed properly in all cases, but any non-ASCII characters appear as gibberish on whichever system was not used to set them. I've confirmed this problem with these two filenames: - 03 - The Foggy Dew with Sinéad O'Connor.flac - Lucky Star - Native Misao (Touhou - Native Faith) ???????????????????×??????.mp4 As a Canadian user, my desktops use the "en_CA.utf8" locale and the only other distros I've found which have this problem are Slax and the 1.0 release of its successor, Porteus, both of which use ISO-8859-1 (latin1) for filenames.
Vinícius dos Santos Oliveira

Tuesday, 04 February 2014, 16:46 GMT

I'm working on that, but I'm not a core developer with commit access, then I need someone to review my patches.

Michael Mrozek

Tuesday, 29 April 2014, 23:58 GMT

Well, if a patch is provided, we can implement it.


Vinícius dos Santos Oliveira

Wednesday, 30 April 2014, 00:47 GMT

But there is a patch:


Notice: Undefined variable: effort in /srv/www/vhosts/ : eval()'d code on line 18 Notice: Trying to get property of non-object in /srv/www/vhosts/ : eval()'d code on line 18 Warning: Invalid argument supplied for foreach() in /srv/www/vhosts/ : eval()'d code on line 18
Date User Effort (H:M)