Mail Archives: opendos/1997/07/14/18:20:44
I've had a deeper look into the long filename business, andI think I
see what is going on.
> From brannanp AT musc DOT edu Tue Jul 15 04:20:04 1997
>
> > In a previous message, Mr M S Aitchison said:
> > > 1. I had a zip file called HOME2.ZIP created on one system, copied
> > > it to diskettem, took it to another PC, deleted it after use, and
> > > created a new zip file called HOME.ZIP straight to diskette. That
> > > now gives me a file with the short name of HOME.ZIP and the long
> > > name of home2.zip. Strange, but probably not a bug in OpenDOS.
> >
> > You're probably right. It's probably a quirk of the implementation of
> > VFAT. I assume the "other PC" used FAT?
>
> Why is an LFN being created for HOME2.ZIP anyway? Shouldn't that be a
> short filename?
I've just tried:
longname/i
pkzip -a c:\bak *.bak (creates BAK.ZIP; this pkzip -s a "legacy" app)
copy c:\bak.zip d:\
dir d:\ (shows SFN: BAK.ZIP, LFN: bak.zip)
longname/u
del d:\bak.zip
pkzip -a d:\bak2 c:\*.bak
longname/i
dir d:\ (shows SFN: BAK.ZIP, LFN: bak2.zip)
The "other PC" I used before was running Win95, but at some stage in
the proceedings I probably had it running in MSDOS7 mode (i.e. no LFN
support). I strongly suspect the above behaviour, which was entirely
under OpenDOS, would also have happened with Win95 (if I had the time
to reboot all those times to enable/disable LFN support). It probably
also happens lots of times without people realising when floppies are
transferred between systems where only some have LFN support.
The way long filenames are stored in FAT directories is hideous. For a
start they take up many directory entries, which can be a problem in
the root directory (which always has a limit on the number of entries).
The method of obtaining the long names is inefficient and susceptible
to things going wrong (mainly legacy apps, but that was the whole
reason they choose this format, right?)
What is going on in the example is that a legacy app creates a filename
with capitals only in the directory entry, irrespective of the case
supplied in the command line (as per normal DOS, even though there is
LFN support). This is reasonable enough, since compatibility is
important and it would be difficult for DOS to realise that the "bak"
supplied in the command line corresponds with "BAK.ZIP" being created
on disk, so it shouldn't unilaterally decide to change the case of the
file being created. After that, I use the built-in copy command to put
this file on a different disk... you might think that because the file
is known on disk as BAK.ZIP the copy command would preserve the case
when creating the copy on D:\, but it goes by the case of the file in
the copy command line. It is reasonable that asking to copy "bak.zip"
finds and copies "BAK.ZIP"; this is what most DOS users would expect,
is compatible with Win95 and existing batch files, and is what what
expect when we say that it "preserves case but is case-insensitive".
The fact that it goes by the case in the copy command rather that
existing filename is something that isn't such a hot idea, but I can
live with that.
As somebody else commented, the fact that it resorts to the LFN method
(of creating extra hidden directory entries, with a special format that
allocates two bytes per character of the original name) to store the
short-but-not-all-capitals name is a design decision that seems strange
when you think that they could have simply stacked those lower-case
letters in a single (and otherwise normal) directory entry, but I can
see how this is needed for compatibilty, so I can live with that as
well.
Now for the real problem:
When this file is deleted on a non-LFN system, the deletion process
doesn't touch those special hidden directory entries. If a new file is
then created (reusing the same directory entry, in this case), the
directory appears to a LFN system as having a long filename belonging
to the new Short FileName, which is w-r-o-n-g !
There is a simple system built into the LFN design that allocates
sequence letters at the start of each hidden special LFN hidden entry,
and a checksum of the SFN. Possibly the OpenDOS implementation isn't
checking the checksum correctly, but in any case there is a probability
that sometimes the checksum will seem to be correct, simply because
only 256 different checksums are possible.
Of course, the LONGNAME support for OpenDOS is still in the early
stages, and might have some minor bugs (the conversion of longname.pas
to LONGNA~1.PAS is an example), but the major ones cannot be fixed
without making the system incompatible with Win95 (at least as far as I
can see). However, I expect this is still a good start, and applications
can start using the DOS calls to access long filenames now, while people
work on ext2fs support or hpfs or whatever, and let it use these new
apps without the MS kludge and all its associated problems.
-------------------------------------------------------------------------------
Mark Aitchison, Physics & Astronomy \_ Phone : +64 3 3642-947 a.h. 3371-225
University of Canterbury, </ Fax : +64 3 3642-469 or 3642-999
Christchurch, New Zealand. /) E-mail: phys169 AT csc DOT canterbury DOT ac DOT nz
#include <disclaimer.std> (/' Callsign: ZL3TQE
-------------------------------------------------------------------------------
- Raw text -