On Wed, Jan 7, 2009 at 3:54 PM, Eric Wittersheim
<eric.wittersh...@gmail.com> wrote:
> Is there anyway to enforce a limit (Windows Server 2000
> and 2003) on the length of file names?

  Not that I know of.  If you find one, let me know, 'cause I got the
same problem in different ways.

  Part of the problem is that not all parts of Windows have the same
path/file name length limits.  Reportedly NTFS itself and the innards
of the NT kernel can handle names on the order of thousands of
characters long, but that's mainly academic because the higher-level
stuff falls apart much earlier.  The Win32 subsystem (which
practically everything uses) is limited to 255 characters, I believe.
Vital system components -- like Windows Explorer and the shell
libraries -- seem to have even shorter limits.

  One of my favorites is users creating files in their local profile
that work just fine, but then the roaming profile sync code pukes
trying to sync back to the server.  (Though I haven't seen that in a
while; it may have been fixed in XP SP2.)

  Another part of the problem is that path name lengths can vary
depending on how the system is "seeing" a file.  For example, if I
have C:\Company\Shared\Quality\Public\QMSDocs on the server shared as
QMSDocs, and the workstations map that share as drive Q:, and then
there's 
Q:\some\really\absurdly\ridiculously\ludicrously\long\path\name\to\a\file.doc,
then it may be okay for the mapped path on the workstation, but on the
server it will be
C:\Company\Shared\Quality\Public\QMSDocs\some\really\absurdly\ridiculously\ludicrously\long\path\name\to\a\file.doc
which pushes Explorer over the limit.  Result?  You can access the
files from Explorer on a workstation, but not Explorer on the server.

  The filesystems typically used on CDs and DVDs have their own limits
which are different from all of the above.  So one thing that may help
the CD archive scenario is to put all the files into an archive format
which handles really long file names, like 7-Zip's .7z format.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to