Problems in filename aliases (8.3 names) in Win32 - Paper

General Macro Scheduler discussion

Moderators: Dorian (MJT support), JRL

Post Reply
User avatar
Bob Hansen
Automation Wizard
Posts: 2475
Joined: Tue Sep 24, 2002 3:47 am
Location: Salem, New Hampshire, US
Contact:

Problems in filename aliases (8.3 names) in Win32 - Paper

Post by Bob Hansen » Fri Nov 07, 2003 1:08 am

In response to another question ( http://www.mjtnet.com/usergroup/viewtop ... =2783#2783 ), it made me think of this problem that I first read about when I purchased XXCOPY program. I have provided the content of the bulletin here for reference. The link to the original is here:http://www.xxcopy.com/xxcopy03.htm.

(I will also mention how happy I am with XXCOPY product while I am at it). :D

:idea: :arrow:
XXCOPY TECHNICAL BULLETIN #03
--------------------------------------------------------------------------------
From: Kan Yabumoto [email protected]
To: XXCOPY user
Subject: Problems in filename aliases (8.3 names) in Win32
Date: 1999-11-27
===============================================

Background:

When Microsoft implemented the long filename in Windows 95,
it came up with a scheme which assigns an alias (or short name in
the so-called 8.3 format) for every long name. Typically, a short
name starts with the first 6 letters in the long name followed by
a tilde and a digit, (numeric tail like XXXXXX~1.XXX), discarding
remaining characters except the three-letter extension. The short
name is synthesized by the file system driver for the volume, in
such a way that all filenames become unique one another within
a given directory. The rule to assign the numeric tail is very
simple; it picks the smallest decimal value not yet claimed in the
directory.

As long as the aliases are used by legacy programs to access files,
the actual filename assigned to a file should not be very important.
But the truth is that even Windows 95 itself accesses certain files
using their short name aliases. One notable situation is when the
most primitive virtual drivers (VxD) are loaded at the beginning
of Windows 95 system start up sequence. Since the long name support
is provided by a module called IFSMgr (InstallableFileSystem Manager)
which is itself a VxD module, locating and accessing the VxD files
are all performed strictly using the short name alias. If you
examine various parts of the system registry, you will find many
8.3 name strings. In short, the system relies on the 8.3 naming
scheme in a very crucial manner.

The problem:

The problem arises when a directory contains a number of files
whose aliases share a common base part (differing only by the numeric
tails). When you copy these files to another directory, the
aliases will be assigned by the simple (first-come-first-served)
algorithm, the first such file copied to the destination directory
will have numeric tail of ~1 regardless of what was its alias
in the source directory. Therefore, the Windows operating system
does *NOT* preserve the alias after copying. We consider this a
very serious defect in the file system design. Most file copy
programs ignore this aspect in file copying. This includes
Explorer (drag-and-drop), COPY, and XCOPY.

Example:

Here, we make a simple sequence in a DOS Box to illustrate the point.
It is assumed that you have the \autoexec.bat file handy (can be any
file). Let us create a pair of files with names that would have the
same short name base for the alias.

C:\> mkdir \src
C:\> copy \autoexec.bat \src\LongNameA.bat
C:\> copy \autoexec.bat \src\LongNameB.bat
C:\> dir \src

LONGNA~1.BAT 1234 11-21-99 11:27p LongNameA.bat
LONGNA~2.BAT 1234 11-21-99 11:27p LongNameB.bat

Use the traditional method to copy the files. When you use another
method like Drag-and-Drop, you would get the same result. First,
pick the file whose short name numeric tail does not end with ~1.

C:\> mkdir \dst
C:\> copy \src\LongNameB.bat \dst
C:\> copy \src\LongNameA.bat \dst
C:\> dir \dst

LONGNA~1.BAT 1234 11-21-99 11:27p LongNameB.bat
LONGNA~2.BAT 1234 11-21-99 11:27p LongNameA.bat

Here, the first file created in the destination received the numeric
tail of ~1, even though its alias in the source was not that.
If you don't see the difference in the left hand side (the aliases),
see the long names to your right (---B and ---A are opposite).

Enter XXCOPY:

Now, try the same operation using XXCOPY in the \new directory.

C:\> mkdir \new
C:\> xxcopy \src\LongnameB.bat \new
C:\> xxcopy \src\LongnameA.bat \new
C:\> dir \new

LONGNA~2.BAT 1234 11-21-99 11:27p LongNameB.bat
LONGNA~1.BAT 1234 11-21-99 11:27p LongNameA.bat

Here, the files in the \src directory and in the \new directory
match exactly (both the long names and the aliases) albeit the
new order reflects the order of copying.

Other cases:

The above example is just one of the many problems with aliases.
For example, when you delete the file with the numeric tail of
---~1 in the source directory and copy the files; the first
files copied to the destination will be assigned with an alias
ending with ---~1. In essence, the short name alias is
systematically synthesized by Windows kernel without regard to
what the original alias in the source directory was. This kind
of discrepancies in file and directory names lead to subtle but
serious problems which are often very difficult to even diagnose.

How safe is XXCOPY?

XXCOPY performs the alias name change using only published
standard Win32 file I/O API. XXCOPY does not attempt to
manipulate the raw directory data structure of the file system.
Nor does XXCOPY perform any unorthodox techniques to implement
the alias matching feature. The operation utilizes a combination
of simple file-renaming system calls. Therefore, it is completely
safe.

On the other hand, when the destination directory already has
a file with the needed alias (i.e., a case of alias name
collision), XXCOPY does not perform such an operation which
would otherwise create an invalid directory data. Of course,
the same name for more than one file is No No in a file system.

Since XXCOPY supports remote machines over a network, the alias
(8.3 name) support function also works across network.

Win95/98 and WinNT/2000/XP:

If your use a dual-boot system (Win95/98 and WinNT/2000/XP), there
is one more pitfall which is related to the shortname.
Please read our new article, XXTB #08.

© Copyright 2003 Pixelab, Inc. All rights reserved.
Also note reference to additional info on this subject for dual-boot systems
Hope this was helpful..................good luck,
Bob
A humble man and PROUD of it!

Post Reply
Sign up to our newsletter for free automation tips, tricks & discounts