File change detection utility for Win 9X/ME

[Zvi Netiv]

(e-mail address removed) wrote:

I believe we covered all that was worth saying and exhausted the subject. Do
with it what you like.

Regards, Zvi

 

[Zvi Netiv]

I remembered that I have an ME boot floppy that I used to troubleshoot
a friend's PC. Sure enough, LFN support is absent in DOS. I see that
LFN FAT entries are protected by having the R,S,H, and V (volume)
attributes set.

LFN are entries in directory blocks, not in the FAT, and they aren't protected
that way. What you see (you must have browsed through a directory with a disk
editor, DiskEdit probably), is part of an LFN entry, which the disk editor
misinterprets as attributes.

Think: If the above speculation was correct, then all files and directories
having long filenames would be read-only, hidden, system, and volume names! If
so, then how come they aren't? ;-)

Moreover, if we were dealing with true attributes, then they could be changed by
the system. Yet these apparent "attributes" aren't changeable.

Without going into deeper technicalities, what you thought were LFN "attributes"
are just part of a special structure that precedes the LFN, indicating that the
following blocks should be interpreted as LFN.

Regards, Zvi

 

[David W. Hodgins]

Think: If the above speculation was correct, then all files and directories
having long filenames would be read-only, hidden, system, and volume names! If
so, then how come they aren't? ;-)

Just to clarify,

Files with short names only have a single entry in the directory table with among other
things, the short name, and the file attributes.

Files with long names have an entry for the corresponding short file name, with the
actual files's attriubtes, plus an additional directory table entry, for each 13 characters
of the file's name. In those additional directory entries, according to
http://www.microsoft.com/resources/.../professional/reskit/en-us/part3/proch17.mspx
the portion of the entry that would correspond to file attriubes, are set to
hidden, system, read-only, volume-ids, so that dos programs that access
the directory table, will hopefully<g> ignore those entries.

See http://www.maverick-os.dk/FileSystemFormats/VFAT_LongFileNames.html
for a description of the directory table entries.

Regards, Dave Hodgins

 

[Ant]

LFN are entries in directory blocks, not in the FAT,

Yes, that sentence doesn't read well. However, MS refer to them as
"FAT Long Directory Entries".

and they aren't protected that way.

That is the only way they are offered *some* protection from old
versions of DOS and software.

What you see (you must have browsed through a directory with a disk
editor, DiskEdit probably), is part of an LFN entry, which the disk editor
misinterprets as attributes.

My version of DiskEdit understands LFNs. Besides, I can look at them
in raw hex if I have to!

Think: If the above speculation was correct,

Not speculation - I understand how directory entries are constructed.

then all files and directories
having long filenames would be read-only, hidden, system, and volume names! If
so, then how come they aren't? ;-)

They aren't, because the mandatory 8.3 entry is not an LFN entry, and
doesn't have the volume attribute set. Any additional entries for an
LFN are effectively "ghost" entries. Having the volume bit set ensures
that most old software will leave them alone. They also have a cluster
number of zero. If LFN-unaware software modifies or deletes an 8.3
name which has an LFN, then the LFN entries become orphaned. This is
not a problem for the file system.

Moreover, if we were dealing with true attributes, then they could be changed by
the system. Yet these apparent "attributes" aren't changeable.

They are true attributes, but LFN entries are not treated as pointers
to files. LFNs always immediatly precede the associated short entry.
If an LFN occurs in the root directory before a volume label entry,
then the label will be incorrectly reported. If an LFN entry is
damaged, then it will become invalid, and detected as such by an LFN
aware system which can look at the stored checksum and perform other
tests. The 8.3 entry will still be there, and contains all information
necessary to maintain the file's integrity.

Without going into deeper technicalities, what you thought were LFN "attributes"
are just part of a special structure that precedes the LFN, indicating that the
following blocks should be interpreted as LFN.

The first byte of an LFN entry is the sequence count (there may be
more than one entry for a long name). For obvious reasons this byte
cannot be 0x00 or 0xE5.

 

[Zvi Netiv]

Since you know all the gory details about LFN entries and directory structures,
then I definitekly got the wrong impression from your mention of "LFN FAT
entries". ;-)

Regards, Zvi

 

[Ant]

Since you know all the gory details about LFN entries and directory structures,
then I definitekly got the wrong impression from your mention of "LFN FAT
entries". ;-)

Yes, just a little misunderstanding I think. Either that, or you were
trolling me for "deeper technicalities"