From: Kan Yabumoto tech@xxcopy.com
To: XXCOPY user
Subject: Short names made by Win95/98 and by WinNT/2K/XP
Date: 2003-10-14 (Revised)
===============================================================================
In our earlier article, XXTB #03, we discussed the subtle problem
of long and short filenames commonly encountered by Windows users.
The problem has been widely known and various solutions have been
devised to handle most such cases. XXCOPY can handle such cases
correctly in most cases.
Unfortunately, when you mix the two types of OS in operation, one
more potential problem may arise.
About the various Windows OS.
Although all Windows operating systems except early ones (Win 3.x)
support long filenames, there is a subtle difference in the
algorithm of alias synthesis by the various OSes. The difference
may adversely affect XXCOPY's effort in preserving the short
filename.
First, let us examine the difference. Windows 95 and 98 use a
straightforward scheme in picking up the short name alias, whereas
Windows NT4, 2000 and XP add a little twist in the way the numeric
tail is generated.
It is easy for anyone to observe the filename related idiosyncrasies.
Just pick a file and repeatedly copy it in a directory under a series
of long names having the same beginning. For example:
mkdir c:\temp
copy c:\autoexec.bat c:\temp\mylongname1
copy c:\autoexec.bat c:\temp\mylongname2
copy c:\autoexec.bat c:\temp\mylongname3
copy c:\autoexec.bat c:\temp\mylongname4
copy c:\autoexec.bat c:\temp\mylongname5
copy c:\autoexec.bat c:\temp\mylongname6
copy c:\autoexec.bat c:\temp\mylongname7
copy c:\autoexec.bat c:\temp\mylongname8
copy c:\autoexec.bat c:\temp\mylongname9
Then, using an appropriate tool, examine the destination directory.
The following table shows the result of the copy operations in
Windows 95/98 and the Windows NT/2000/XP variations.
Longname Windows 95/98/ME Windows NT4/2K/XP
----------------------------------------------------------
mylongname1 MYLONG~1 MYLONG~1
mylongname2 MYLONG~2 MYLONG~2
mylongname3 MYLONG~3 MYLONG~3
mylongname4 MYLONG~4 MYLONG~4
mylongname5 MYLONG~5 MYA476~1
mylongname6 MYLONG~6 MYA486~1
mylongname7 MYLONG~7 MYA496~1
mylongname8 MYLONG~8 MYA4A6~1
mylongname9 MYLONG~9 MYA4B6~1
Whereas the Win9x OSes use a simple decimal number in the numeric
tail, the WinNT family OSes follow the same pattern only in the
first four cases. After that, they start using a 4-digit
hexadecimal number in the middle of the 8.3 name as the
distinguishing part (only the first two letters remains the same).
The hexadecimal value is probably a hash value for the string to
supposedly shorten the filename matching operation which could be
very time consuming. Microsoft programmers chose to keep the first
four match done numerically for the sake of compatibility to the
Win9X systems. What they failed to realize is that they allowed
only the first four such names for compatibility.
The adverse effect of the two alias algorithms.
As long as you use XXCOPY in a homogeneous environment where
the files are generated under one OS, XXCOPY can preserve the
short name. But, when you have a mixed environment (e.g., with a
dual-boot system), you may copy a directory with many similar
names which were created under one OS and then perform a directory
copy operation using XXCOPY under the other OS, XXCOPY may not be
able to preserve the short name.
One consolation is that the great majority of files will receive
the correct short name alias using XXCOPY since the numeric tail of
the first four aliases in a directory are common in all Windows OSes.
Therefore the problem should be quite rare. Ironically, if your
system has many Microsoft software packages, you will find quite
a few directories which all start like:
"\Program Files\Microsoft xxxxx"
One can argue that exactly because it is so rare, this phenomenon
would not be widely known. Therefore, when the rare problem occurs,
it will take many agonizing hours for the user to discover the
cause of the problem.
Then, what happens with XXCOPY?
Since XXCOPY does not access the raw directory contents in the
process of preserving the short name alias, its magic does not work
all the time. We cannot do much about this problem without making
the XXCOPY utility breaking the rules of good programming practice.
At least we can list the situations where the potential problem may
arise and how you can avoid it.
1. Stay within the 8.3 naming convention if possible.
2. Stay away from a dual-boot system if possible.
3. If you have a dual-boot system and you switch the OS from
time to time, make sure a directory is written exclusively
under one OS if possible.
4. Finally, when you have to copy a directory, use XXCOPY and
perform the copy operation under the same OS in which the
files in the directory were created.
5. In a networked environment with different types of OS between
the source and the destination directories, expect the worst.
Note that although it is ideal that when you copy a directory,
all the files in the destination should be identical to those in
the source, in most case, it is not the end of the world. As a
matter of fact, in most cases, the discrepancies in short names
do not cause any problem. As long as the files and directories
that are affected by this problem is "non-system" files, the
problem would be benign if present at all.
In the case of Windows 95/98, the most well documented problem
which are associated with the unmatched short name is a few
directory and filenames which are stored in their short name
alias in a few critical cases in the system registry. Since
Windows 95/98 references these files at the system initialization
time (locating and loading VxD files using short names), the
difference would be life and death (that is, success and failure
in system initialization).
A final advice with XXCOPY:
If you have a large number of collided aliases (where the short
name distinctions are made by the synthesized numeric tail only),
and you are copying across OSes (from Win95/98 to WinNT/2000/XP
or vice versa), we suggest you turn off XXCOPY's short name
preservation switch by /NX0 in order to avoid the time consuming
and futile effort by XXCOPY.
[ Table of Contents ]
[ << ]
[ Show as Detached ]
[ >> ]
|
On-Line Manual 
XXTB #006