[prev] [thread] [next] [lurker] [Date index for 2005/05/18]
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