Post Reply 
50g: copy all stored objects to SD card individually
10-16-2016, 10:55 AM (This post was last modified: 10-19-2016 07:10 PM by matthiaspaul.)
Post: #14
RE: 50g: copy all stored objects to SD card individually
(10-16-2016 02:09 AM)DavidM Wrote:  
(10-15-2016 09:46 PM)matthiaspaul Wrote:  What codepage is displayed by CHCP under CMD?
That's strange given that "Ź" isn't a character defined in codepage 437. I was assuming something like codepage 852 or 1250, even though this would not be a common default setting for a US-based system (437 is).

Well, CHCP displays the system codepage (of the subsystem), not necessarily the codepage of the display (or actually the console window). Does

MODE con:

report a different codepage under CMD?

Does the "Ź" character change to something different, if CMD is switched from full-screen mode to windowed mode? Background: Due to limitations in the character repertoire in the display font in windowed mode, it is possible that Windows does not show some characters correctly in windowed mode (it depends on the size of the console window and which font and character size is selected in the console window Properties>Font), whereas it always does in full-screen mode, because the codepage reported by MODE con: is the codepage of the font uploaded into the display adapter in full-screen mode, and it is impossible to switch the con: device to codepages which aren't supported in full-screen mode (I don't know if this still holds true for Windows 7, but in older versions, these text mode display fonts were stored in .CPI files). However, with more complete support in newer Windows versions, I thought this would be something of the past...

(10-15-2016 09:46 PM)matthiaspaul Wrote:  No: While it is possible to disable SFNs in NTFS, this is impossible for FAT. Even though Microsoft calls the FAT SFNs "alias names", the SFNs are the *actual* file names, and the LFNs rather than the SFNs are optional. A LFN can be seen as some kind of "extended attribute" loosely attached to the directory entry holding the SFN (and all the other information about the file). A SFN may contain invalid characters and be distorted to the point of not resembling the corresponding LFN any more at all, but it is impossible for a SFN not to exist in the FAT filesystem.

I suppose Microsoft needs to change their help output for "dir", then. Smile It states the following for the /X switch:
  /X          This displays the short names generated for non-8dot3 file
              names.  The format is that of /N with the short name inserted
              before the long name. If no short name is present, blanks are
              displayed in its place.
Yes, this help text is highly misleading. However, as we can see from the first sentence, Microsoft's description seems to be written from the perspective of the API, not from the perspective of the filesystem: On API level, the normal file names users deal with (today) are the long file names, and by default the system automatically derives some 8+3 short file names from these names for backward compatibility. AFAIK, this can be switched off for NTFS. However, the generation of SFNs cannot be suppressed for FAT because the data structures of the FAT filesystem fundamentally rely on these entries - the SFNs are part of the (fixed-size) 32-byte directory entries which hold all the information about a file (except for the LFN). At most, you could store blanks or invalid characters in their place, but then you'd end up with invalid SFNs, not "no SFNs". IIRC, the system will report the SFN through the LFN API if a file has no LFN.

BTW. From the DIR /X help in 4DOS: "The short filename is left blank if the short name and the long name are the same."

(10-15-2016 09:46 PM)matthiaspaul Wrote:  And how was this file displayed by DIR /X exactly? "AAAAAZBBBBB" and "AAAAAZ~1" or something different?
10/15/2016  07:52 PM                19 AAAAAì~1     AAAAA?BBBBB
"Z" and "?" rather than "Ź"? It seems, something went wrong here in the transition of this screen copy.

Quote:Just out of curiosity, I decided to try the "bad character test" using a different SD card. All attempted character tests were successful using that card, including the x8D test that failed before. This led me to believe that I had some type of file system corruption on the original SD card, so I reformatted it and tested again. Now all filename tests are working properly with Windows on that card as well. So it's apparent that some type of file system corruption was causing the original problem.
I'll be on the lookout for more strange issues like that, and I'll retest if I start seeing other problems. So my concerns about inaccessible files are no longer a result of embedded characters in the names. Just lurking file system corruption!
Given the unusually high file system corruption rate (, I suspect that the calculator is causing this corruption in the first place. If this happens again, inspecting the directory entry of an "undeletable" file with a disk editor might reveal the cause of the problem. Perhaps CHKDSK or SCANDISK would give some useful error message as well.
Quote:As an example, I'm curious what will happen if the computer writes a LFN using Unicode (if that's even possible on a FAT-formatted card).
Of course, that's possible. In the FAT filesystem LFNs are always stored in the UCS-2 format, so (putting the buggy implementation in the calculator aside) LFNs are - by definition - always expected to be given in Unicode with the sole restriction that only 16-bit Unicode characters are supported. (On higher levels, filenames may be given in the more convenient UTF-8 format, but this is just another storage format, not a different character set.)



"Programs are poems for computers."
Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: 50g: copy all stored objects to SD card individually - matthiaspaul - 10-16-2016 10:55 AM

User(s) browsing this thread: 1 Guest(s)