Allgemeine Frage zu Longfilenames in FAT

[poot (Gast)]

Hallo zusammen,

ich schreibe gerade einen kleinen FAT16/32 Treiber, der mit möglichst 
wenig RAM und ohne dynamische Allokationen auskommen muss. FAT-Code 
gibts zwar wie Sand am Meer, aber ein Großteil unterstützt entweder 
garkeine LFNs oder ich werde nicht schlau draus. Die Micro$oft 
Spezifikation geht zwar drauf ein, beantwortet mir aber folgende Frage 
nicht:

Ein LFN-entry in einem Directory wird ja als zu einem Shortfilename(SFN) 
zugehörig identifiziert per 8Bit-Checksumme, die aus dem SFN generiert 
wird. Aber spätestens ab 257 Dateien kommt es in dem Raum doch zu 
kollisionen und bei 50 Dateien ist die Wahrscheinlichkeit schon >99%. 
Das ist natürlich nicht soooo der Hit. Mir werden bei einem Listing von 
großen Ordnern dann viele LFNs doppelt oder mehrfach angezeigt. Dann 
hatte ich überlegt, dass ich die Longnames in Shortnames konvertiere und 
wenn das nicht übereinstimmt, sehe ich nach dem nächsten LFN eintrag. 
Wenn es aber dann mit nummerierten SFNs a la "FOOBAR~6TXT" losgeht, 
funktioniert das auch nicht mehr (die lassen sich ja nicht 
deterministisch alleine aus dem LFN erzeugen). :/

Also meine Frage: Wie komme ich eindeutig an die LFNs dran?

[Martin (Gast)]

Die LFN werden im Dokument fatgen103.doc (gibt es bei MS) sehr gut 
erklärt. Lange- und kurze Namen stehen immer zusammen, die Checksumme 
bezieht sich nur auf diesen Sachverhalt.

[poot (Gast)]

Vielen Dank für die schnelle Antwort! :)
Also ich bin davon ausgegangen, dass die LFN halt auch fragmentiert im 
ganzen Ordner verstreut sein können.
Nur damit ich das absolut nicht falsch vestehe: Die sind also stets 
vor dem shortentry? (Zudem in absteigender Reihenfolge der 
sequenznummer?) Dann bräuchte ich ja garkeine Checksummen generieren oO

[Martin (Gast)]

Hier ein Auszug aus dem o. g. Dokument von MS.

...
A set of long entries is always associated with a short entry that they 
always immediately precede.  Long entries are paired with short entries 
for one reason: only short directory entries are visible to previous 
versions of MS-DOS/Windows.  Without a short entry to accompany it, a 
long directory entry would be completely invisible on previous versions 
of MS-DOS/Windows.  A long entry never legally exists all by itself.  If 
long entries are found without being paired with a valid short entry, 
they are termed orphans.  The following figure depicts a set of n long 
directory entries associated with it's single short entry.

Long entries always immediately precede and are physically contiguous 
with, the short entry they are associated with.  The file system makes a 
few other checks to ensure that a set of long entries is actually 
associated with a short entry.

...


...


First, every member of a set of long entries is uniquely numbered and 
the last member of the set is or'd with a flag indicating that it is, in 
fact, the last member of the set.  The LDIR_Ord field is used to make 
this determination.  The first member of a set has an LDIR_Ord value of 
one.  The nth long member of the set has a value of (n OR 
LAST_LONG_ENTRY).  Note that the LDIR_Ord field cannot have values of 
0xE5 or 0x00.  These values have always been used by the file system to 
indicate a "free" directory entry, or the "last" directory entry in a 
cluster.  Values for LDIR_Ord do not take on these two values over their 
range.  Values for LDIR_Ord must run from 1 to (n OR LAST_LONG_ENTRY). 
If they do not, the long entries are "damaged" and are treated as 
orphans by the file system.
...

[poot (Gast)]

Ok ist stell mich in ne ecke un schäme mich... ;)
Nach 30 seiten Micro$oft Spezifikation werden die Augen schonmal was 
müde, sorry.

Vielen Dank!