XXCOPY
[ Back to Table of Contents ] [ << ] [ >> ]

XXCOPY TECHNICAL BULLETIN #03


From:    Kan Yabumoto           tech@xxcopy.com
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:

2  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 2016 Pixelab All rights reserved.

[ XXCOPY Home ] [ Table of Contents ] [ << ] [ >> ]

Join the XXCOPY group