ADSM-L

Re: NT long file names

1999-05-19 10:07:01
Subject: Re: NT long file names
From: "Helms, William H." <william_h_helms AT MD.NORTHGRUM DOT COM>
Date: Wed, 19 May 1999 10:07:01 -0400
We had a similiar issue with IBM and have submitted an ADSM reqirement
request for a fix to be developed.  The problem occurs when restoring files
that have been successfully backed up without error on an NT 4.0 platform
under the following circumstances; a file is active and is named with a long
file naming convention for example, 'TESTFI~1.XLS' which uses the '~'
character in the actual name. A second file exists which has a legitimate
long name and a short file name that hashes to the same name as the first
file.  When the file with a longer than 8.3 name is restored first, the file
with only an 8.3 style name will not restore.  This is because NT has
generated a short file name for the first file that conflicts with the
actual filename of the second file.  IBM attributes this to a bug in NT
code, as you noted, and has documented it as such in APAR IC23640.  In an
ideal situation, any file that is backed-up, should be restorable by ADSM.
At a very minimum, ADSM should skip these files and complete the rest of the
restore. Then, at the end it should conspicuously identify these files and
the possible situation.  One work around would be to add a switch that
forces the files with only an 8.3 name to be restored first, (or
separately).  Another workaround would be to determine if the "duplicate
file name" is being caused by this situation. If such is the case, the
client could temporarily rename the long filename file, (to its true short
filename) restore the short filename file, and then return the original file
to the proper long. Our NT support group, spoke with Microsoft support about
this issue.  They said that there isn't a way to programmatically create the
short file name and the ADSM software probably should restore the short
files first.  Nothing has happened to this point.



> -----Original Message-----
> From: Jack Revette [SMTP:jack.revette AT DOWCORNING DOT COM]
> Sent: Wednesday, May 19, 1999 8:55 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      NT long file names
>
> I have a current problem (87425) open with IBM where NT 3.51 ADSM 3.1 0.6
> client was doing a selective backup to an AIX 4.3 ADSM 3.1.2.20 server and
> after 15+ hrs and 39GB of data encountered a fully qualified dataset name
> of
> length 270 and dropped an informative message (ANx4005E) on both client
> and
> server log. Ten minutes later the client aborts.  IBM's response is that
> it's not an ADSM problem as Microsoft doesn't support file names greater
> than 256 and points me to a microsoft doc (search on the MS site for 'Path
> Too Long Error Message When Exceeding MAX_PATH ').  This doc does support
> IBM's position re lfn, but also notes that NTBackup has no problem with
> such
> files.
> Last June in this forum, Andy Riebeck indicated similar concerns with NT
> file names and pointed out certain limits (_MAX_DIR = 256, _MAX_EXT= 256,
> _MAX_FNAME = 256, _MAX_PATH =260).
> I can understand ADSM not processing 'errant' files, but I can't accept
> ADSM
> abending or aborting backups when such a filename is encountered.  And in
> general, IBM seems to agree with this position (note fixes IC20506,
> IC18235).
> Some questions:  Is anyone aware of attempts to remove the restriction of
> the fully qualified dataset name being no greater in length than 256 or
> 260?
> If no, is there any way to prevent users from creating such datasets?
>
> ***********************************************************
> This email transmission and any files that accompany it may
> contain sensitive information belonging to the sender. The
> information is intended only for the use of the individual
> or entity named. If you are not the intended recipient, you
> are hereby notified that any disclosure, copying,
> distribution, or the taking of any action in reliance on the
> contents of this information is strictly prohibited. If you
> have received this email transmission in error, please
> immediately notify the Security Administrator.
> Security.Administrator AT dowcorning DOT com
> ***********************************************************
<Prev in Thread] Current Thread [Next in Thread>