Hi List,

Hoping someone's experience can help with what I can't believe is
still an issue in filesystem management and what it might mean.
According to Microsoft (http://support.microsoft.com/kb/320081/en-
us) , NTFS supports paths that are much longer than 255 characters,
but other applications that run on top of Windows may not. While I
can't call them liars, I've repeatedly found that even Windows
Explorer and Robocopy have problems copying and deleting files that
have extremely long file paths.

So my question is:

Is there a way (third-party tool, some obscure windows trick, etc) to
*make certain* that users do not create paths greater than a certain
#? If not prevent, can we at least make it easier for the user to
know that they are reaching potential problem areas with their filing
practices? How do companies deal with this problem when doing file
migrations for upgrades and disaster recovery? There must be some way
to manage this issue.

Anyone with commentary on anything related to 256 character
limitations in production file server environments would be greatly
appreciated.

Potential products to investigate are also welcome!

Thanks in advance,
Rob

See below.

"dontinou" <robert.yung@l-3com.com> wrote in message
news:c666e98b-dc68-4e40-a6d4-de2a1878b912@h1g2000prh.googlegroups.com...
> Hi List,
>
> Hoping someone's experience can help with what I can't believe is
> still an issue in filesystem management and what it might mean.
> According to Microsoft (http://support.microsoft.com/kb/320081/en-
> us) , NTFS supports paths that are much longer than 255 characters,
> but other applications that run on top of Windows may not. While I
> can't call them liars, I've repeatedly found that even Windows
> Explorer and Robocopy have problems copying and deleting files that
> have extremely long file paths.

*** Robocopy Version XP010 has no problem with very long paths.

> So my question is:
>
> Is there a way (third-party tool, some obscure windows trick, etc) to
> *make certain* that users do not create paths greater than a certain
> #? If not prevent, can we at least make it easier for the user to
> know that they are reaching potential problem areas with their filing
> practices?

*** No, there isn't, because the relative path seen by the user (which
*** is usually inside a share) may be considerably shorter than the
*** absolute path on the hosting disk drive.

> How do companies deal with this problem when doing file
> migrations for upgrades and disaster recovery? There must be some way
> to manage this issue.

*** They tell their users to put their information into their files, not
*** into the file + folder names.

> Anyone with commentary on anything related to 256 character
> limitations in production file server environments would be greatly
> appreciated.
>
> Potential products to investigate are also welcome!

*** I am not aware of any. However, since both robocopy and ntbackup
*** will handle very long path names, there should be no problem with
*** migrations and disaster recovery.