File change detection utility for Win 9X/ME

  • Thread starter Thread starter null
  • Start date Start date
(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
 
Ant said:
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.
Click to expand...

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
 
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? ;-)
Click to expand...

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
 
Zvi Netiv said:
LFN are entries in directory blocks, not in the FAT,
Click to expand...

Yes, that sentence doesn't read well. However, MS refer to them as
"FAT Long Directory Entries".
and they aren't protected that way.
Click to expand...

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.
Click to expand...

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,
Click to expand...

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? ;-)
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
 
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
 
Zvi Netiv said:
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". ;-)
Click to expand...

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