Hi,
I have found the cause of the problem and a way round it.
These files owned by the DOS name space have been around since before
Novell changed the way DOS files were written to disk to match the
format that Microsoft wrote DOS files to disk. I think this was changed
around Netware 4. These files have been around and on-disk untouched
since then and so retain these old attributes.
If the files are renamed in-place then they become owned by the LONG
name space and so the DOS namespace issue is eradicated. Using JRBs
whodidit.exe to identify the DOS owned files and then renaming the files
with the same name, but lower-case, fixes them up. We have a large
number of these files and any way of sidestepping this problem would be
preferable.
Renaming directories in the DOS namespace may cause problems for Mac
users that may have links or shortcuts with the path in.
The new ClientPak for Netware came out on Monday. This is version 7.2,
I think it resolves some other problems we have been having but I have
only done limited testing. It seems to introduce further problems, very
slow at reading the index for a directed recover, and doing a save-set
recover it restores all long names as short names with a tilde unless
the backup was done with the same version client. The documentation
says it should recover from tapes written by the old, 4.22, client.
Regards,
Andrew Horne
On 9/5/05, Andrew Horne <a.horne AT sheffield.ac DOT uk> wrote:
>> Hi,
>>
>>
>> Running Networker on a Solaris 8 box backing up over 25 Netware 6.5SP3
>> clients, running client 4.22, plus a number of Windows servers.
>>
>> Doing a save set recover to a Netware server I get lots of errors in the
>> log file like this -
>>
>> USRTST:TST/AB_SHARE/AB_SHA~1/SDU/WEBBAC~1/EDBASE~1/IMAGES/<0>
>> "USRTST:TST/AB_SHARE/AB_SHA~1/SDU/WEBBAC~1/EDBASE~1/IMAGES/<0>" no data
>> saved - try an earlier version
>> USRTST:TST/AB_SHARE/AB_SHA~1/SDU/WEBBAC~1/EDBASE~1/IMAGES/<1>
>> "USRTST:TST/AB_SHARE/AB_SHA~1/SDU/WEBBAC~1/EDBASE~1/IMAGES/<1>" no data
>> saved - try an earlier version
>>
>>
>>
>> The data appears to be recovered ok but when the number of errors runs
>> in to the hundreds or thousands it isn't possible to say that that is
>> the case with any certainty. Also the list of errors reported may
>> include other actual errors where data hasn't been restored correctly,
>> ploughing through a log file looking for real as opposed to benign
>> errors isn't something I fancy doing when there is an emergency
situation!
>>
>> I've checked the archives and the internet, a few other people have
>> reported the same problem. Is there a fix for this?
>>
>> Cheers,
>>
>> Andrew Horne
--
Andrew Horne
The University of Sheffield
Corporate Information & Computing Services
285 Glossop Road
Sheffield
S10 2HB
E-Mail a.horne AT sheffield.ac DOT uk
Tel: (0114) 222 3068
-
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|