Just a warning derived from another bad luck story.
We had once a restore attempt for a server with many "Microsoft blah-blah"
directories under "C:\Program Files". Despite the fact it was Windows 2000
Advanced Server with MS SQL 2000, it simply disregarded long names. For
some unknown reasons M$ installer put in the registry the SQL path values
as "C:\Progra~1\Micros~3\..." ?!?
At restore time TSM was promptly restoring directories "Microsoft <A>",
"Microsoft <B>", "Microsoft <C>", "Microsoft <D>". It happened that in
alphabetical order the "Microsoft SQL Server" directory got to be fourth,
and was restored with 8.3 equivalent "Micros~4". Opening a Command Prompt
window and doing a "cd progra~1\micros~3" led us to the Office directory
and SQL Server did not worked. The admin of that box had to reinstall it
to get it working!
So the 8.3 problem is still alive beyond any DOS and Win 3.1/9x/Me. Good
example of design limitation which is carried on for backward
compatibility!
Bottom line: even when everything seems to be restored, you still may have
an inconsistent restore. So test and verify, and again test-test-test and
verify!
Zlatko Krastev
IT Consultant
Roger Deschner <rogerd AT UIC DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
12.11.2003 23:29
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: client restore fails trying to replace files that
don't exist
Hmmmm. Very interesting! Thanks, Wanda - this actually gives me
something to go on. All WinME systems use 8.3 filenames deep down
inside, because WinME was still built on a MS/DOS kernel. (Last of that
species!)
This might also explain why a circumvention we tried worked: Restore to
C:\abacadabra didn't work. So I tried a restore to a different location
C:\temp which worked. Then to my surprise, I was able to successfully
rename C:\temp to C:\abacadabra. The reason it worked was that rename
correctly chose a different 8.3 name for C:\abacadabra than for possibly
existing directory C:\abacadabrashazam. Now I need to go check this
client and see if he also has C:\abacadabrashazam on his computer, and
look and see what 8.3 names already exist that might cause a collision.
If this is true, then a full "bare metal" restore should also work OK.
Then all files are restored at once, and even if the new 8.3 names are
different, at least there will not be collisions because each long name
will map to a unique 8.3 name.
The problem arises when the client does piecemeal restores - and then
goes back in for more. I have always regarded the piecemeal restore
method to be the worst for resynchronization issues, and now I have
another reason to discourage it.
I don't know if this business of collision in the 8.3 namespace will be
it, but this certainly gives me something to go on to try to find it.
Thanks a lot!
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
On Wed, 12 Nov 2003, Prather, Wanda wrote:
>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
>
|
