Windows filesystem api

[prev] [thread] [next] [lurker] [Date index for 2005/05/18]

From: Bruce Richardson
Subject: Windows filesystem api
Date: 14:59 on 18 May 2005
Item 1: maximum length of pathname

Theoretically, this is 256 characters.  Some libraries, however, can
only cope with 255 and crash when passed a 256 character path (little
used ones like the ADO libraries, for instance).  Some of the directory
handling api calls have a 248 character limit.

Item 2: confusion over permitted characters.

The file creation api calls allow a wider range of characters than some
of the file access calls (some of which assume that all files are
only created interactively, through the GUI, which applies limits over
and above those in the underlying file creation system calls).  Thus,
there are file handling calls which cannot cope with files that begin
with a '.' character, even though it is perfectly possible to create
one.

Items 1 and 2, taken together, make it very easy to create files which
you cannot access.  I frequently encountered this at my last job, where
I was (unwillingly) in the position of backing up linux servers in the
regional offices to a path on a linux box which was actually a mounted
Win2k fileshare.  This regularly created files that could neither be
accessed nor deleted.

Item 3: long/short filename insanity

Imagine that your staff are enthusiastic users of the shared filesystem
and that they are also prone to creating files with very similar, long
names, e.g. "Management Meeting Minutes - March.doc" and "Management
Meeting Minutes - April.doc".  Now, this is how you can
have real fun copying those files from one Win32 filesystem with short
filename support to another one:

Windows short filenames are dynamically created when a file is placed in
a directory.  So the March file might have a short name of MANAGE~1.DOC
and the April file a name of MANAGE~2.DOC, the April file having been
created after the March one.  However, when the directory is copied, the
short filenames are not preserved but are created afresh.  The files
will probably be copied in lexical order, so that the April document
will be copied first and get MANAGE~1.DOC.  You would *expect* the March
document, being copied next, to get MANAGE~2.DOC.  However, the real fun
happens here; it examines the original March file, notices that it has a
short name of MANAGE~1.DOC, remembers that there is already a MANAGE~1.DOC
file in the destination directory and thinks "Aha!  This is actually the
same file, so I will copy one over the other."  Having fucked up the
April document, it then creates a directory entry for the long name of
the March document, with metadata that conflicts with the now borked
April document.

Imagine the mess that results when you copy the original filesystem from
the network to the local disk of a Win2k box before burning the
resulting porridge onto CD.

Last time I looked, all versions of Windows were affected by this issue
and there was no fix.  The only workaround was to turn off short
filename support.

Issues 1, 2 and 3 together show that you cannot trust a bunch of monkeys
who use a GUI for everything to design anything more critical than
winmine.

-- 
Bruce

What would Edward Woodward do?

Generated at 16:00 on 18 May 2005 by mariachi 0.52