ADSM-L

Re: Can anyone confirm if this is a bug or a feature - NTFS problem?

1997-07-09 13:53:14
Subject: Re: Can anyone confirm if this is a bug or a feature - NTFS problem?
From: Peter Thomas <Peter_Thomas AT MANULIFE DOT COM>
Date: Wed, 9 Jul 1997 13:53:14 -0400
From: Peter Thomas on 07/09/97 01:53 PM
Shelagh

I recently did some checking into this...

    Since DFS lends itself to a fairly "deep" directory structure, are
    there any limitations (or requirements) for application programs that
    might be using these trees?

    What I mean is that under "classic DOS", even though sub-directories in
    theory could be nested to any depth, may programs "broke" once the full
    directory path to a file was greater than 63 characters.

    As far as I can tell, under Windows/NT the maximum path length is the
    value MAX_PATH from the C include file <stdlib.h>; this is for the
    fully qualified name

    From stdlib.h

    #define _MAX_PATH   260 /* max. length of full pathname */
    #define _MAX_DRIVE  3   /* max. length of drive component */
    #define _MAX_DIR    256 /* max. length of path component */
    #define _MAX_FNAME  256 /* max. length of file name component */
    #define _MAX_EXT    256 /* max. length of extension component */


I think that even though a user can create a "longer" file name / path
name, if will break the 260 character, maximum length.

Peter Thomas





From: sheelagh.treweek @ COMPUTING-SERVICES.OXFORD.AC.UK on 09/07/97 05:58
      PM CET

Please respond to ADSM-L AT VM.MARIST DOT EDU

To:   ADSM-L @ VM.MARIST.EDU
cc:    (bcc: ADSM)
Subject:  Can anyone confirm if this is a bug or a feature - NTFS problem?





Please can anyone tell me where (if) it is documented what the maximum
filename/filepath length is on WindowsNT Version 4/adsm client 2.1.06
is please? We have had reported to us this problem and have confirmed
that adsm client is not coping with such a long name.

Thanks a lot.
Best wishes, Sheelagh
--
> I have verified that the ADSM does indeed fall over when presented with
> I have verified that the ADSM does indeed fall over when presented with
> a directory/filename combination whose length exceeds 254 characters. I
> created a directory of 159 chars and filename with length of about 163
> chars which would give a total of 362 chars including drive letter and
> directory delimiter (\):
>
> C:\..159 chars...\...163 chars...
>
> The DSMERROR.LOG generated was ass follows:
>
> 07/09/1997 15:25:14  FioGetOneDirEntry(): *** Access to NTFS file
> security information denied, file/dir skipped ***
> 07/09/1997 15:25:14  TransWin32RC(): Win32 RC 234 from
> FioGetOneDirEntry(): getFileSecuritySize
> 07/09/1997 15:25:14  PrivIncrFileSpace: Received rc=131 from
> fioGetDirEntries:  C:
>
\averylongpathnamethathopefullywilltestoutthetheorythatalongpathnameordirec
toryn
amewillcausetheadsmscedulertohaveaprobmeandthereforeallowoucstosendsometing
toibm
>
> The ADSM client was performing an incremental backup and stopped with
> the error:
>
> Internal system error - report how you got this
>
> I think this needs reporting to IBM as a possible bug.

---------------------------------------------------------------------------
---
---
Sheelagh Treweek                         Email:
Sheelagh Treweek                         Email:
sheelagh.treweek AT oucs.ox.ac DOT uk
Oxford University Computing Services     Tel:   +44 (0)1865 273205
13 Banbury Road, Oxford, OX2 6NN, UK     Fax:   +44 (0)1865 273275
---------------------------------------------------------------------------
---
---
=========================================================================
<Prev in Thread] Current Thread [Next in Thread>
  • Re: Can anyone confirm if this is a bug or a feature - NTFS problem?, Peter Thomas <=