ADSM-L

Re: client restore fails trying to replace files that don't exist

2003-11-12 11:08:49
Subject: Re: client restore fails trying to replace files that don't exist
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 12 Nov 2003 11:08:26 -0500
Roger,

I don't know anything about Windows ME.  You may have a bug.

But I have seen something like this on Win2K; the symtom is that you get
prompted for permission to overwrite a file, even when you are restoring
into a previously empty directory.

When I have seen this on Win2K, it has been a problem with 8.3 filenames.
When TSM does restores, it recreates every file, so each long file name gets
a reconstructed 8.3 filename, which may be DIFFERENT from its original 8.3
filename.

If the system has 8.3 filenames turned on, there is a Windows rule that says
how the 8.3 filename gets constructed.

And, you can have "clashes", where 2 files with different long file names
map back into the same 8.3 filename.  The first one restores OK, the second
one TSM tries to restore results in a prompt to overwrite.  It isn't obvious
what is happening, because TSM gives you the error on the LONG file name,
not the 8.3 one.

It is most likely to happen with long filenames that begin with identical
chars and end in very similar characters, for example:

very.long. my file name is a mess.urk
very.long. my file name is a mess.@urk
very.long. my file name is a mess.xurk


The fix for this (again on Win2K) is a registry hack that TURNS OFF the
creation of the 8.3 filename - you can find it in Microsoft's knowledge base
(search on 8.3).

Turn off the 8.3 filenames, finish the restore, then turn them back on
again.

There is no TSM fix that prevents this behavior, because there is no Windows
fix for it.  You can reproduce the same behavior with XCOPY, not just with
TSM.

Again, this may not be your problem.
But it's something to look at.

Wanda





-----Original Message-----
From: Roger Deschner [mailto:rogerd AT UIC DOT EDU]
Sent: Monday, November 10, 2003 6:29 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: client restore fails trying to replace files that don't exist


I'm having a client problem that has gotten me stumped. (And that takes
some doing.)

The client node is Windows ME. The hard drive crashed, they got a new
one, and reinstalled WinME from the original install CD. They started
with an old V3.7 client program when this issue first started, but I
since upgraded them to the latest WinME client, V5.1.6. It didn't help.
(Our server is AIX TSM 5.1.6.5)

The owner of this node decided against doing a total full "bare metal"
restore, and is instead restoring whole directories containing his
documents.

On several occasions, restores are failing like this:

They open the GUI client, and navigate to a directory they want to
restore. They click on it, and click Restore. They leave the default
"Original Location" selected. It begins to issue a series of
"File/Directory already exists" and "File is read/only" error messages.
No matter how many times you tell it that it's OK to Replace, and "Apply
action to all remaining files", it gets stuck asking this question on
the SAME FILE over and over.

I was called to this person's office to diagnose it. They are doing
nothing wrong that I can see. The files and directories being complained
about indeed do not exist yet. I looked carefully in Windows Explorer,
after being sure to turn on Windows Explorer's options to show hidden
files, and show known file types.

I have seen this kind of thing once before, long long ago, and I thought
it was fixed several releases ago. Both client and server are now
up-to-date. Has anybody else seen this?

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu