Notice: Trying to access array offset on value of type bool in /srv/www/vhosts/ on line 649 FS#300 : SuperZaxxon interprets on-disk FAT32 filenames differently than desktop Linux

OpenPandora Main OS

  • 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 - 16.09.2012

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 commented on 04.02.2014 16:46

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 commented on 29.04.2014 23:58

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


Vinícius dos Santos Oliveira commented on 30.04.2014 00:47

But there is a patch:


Available keyboard shortcuts


Task Details

Task Editing