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
>
|
