ADSM-L

Re: Error ANS4007E on restore using 3.1.05 Win95 32-bit clie

1998-09-01 23:45:15
Subject: Re: Error ANS4007E on restore using 3.1.05 Win95 32-bit clie
From: Pete Tanenhaus <tanenhau AT US.IBM DOT COM>
Date: Tue, 1 Sep 1998 23:45:15 -0400
Everything Joanne and Andy have said regarding this problem is true, but I
would add that
Win9x directories don't really have any useful attributes to restore.

Win9x doesn't implement file or directory level security so there are no acl's
or secuirty descriptors to restore, and setting date/time stamps on directories
isn't supported either.

About the only directory attributes which can be set are the DOS standard
attribute bits (r/o, archive, system, hidden)
and other than the archive bit these are somewhat obscure I believe.

Anyway, I guess I missed the point in the original append that this is a GUI
specific problem, and as Joanne mentions
we will have it fixed in PTF 6.

Pete Tanenhaus, ADSM NT Client Development
---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 09/01/98
1/98
11:17 PM ---------------------------


ADSM-L AT VM.MARIST DOT EDU on 09/01/98 08:40:36 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Error ANS4007E on restore using 3.1.05 Win95 32-bit clie


Hi Bob,

I've tried the scenario and was able to recreate the problem you're seeing.  It
is a bug in the GUI code.
We're supposed to create the directory using the drive letter instead of the
UNC name for this particular
path and we didn't.  The OS creates the directory anyway and that's why you see
everything is being
restored.  The drawback is that the directory attributes are not restored.  If
the directories exists, you
should not see this problem.  The directory attributes should have been
restored as well.

I understand that you've been communicated with Andy Raibeck offline.  Please
continue to do so to
open an apar for this.  It will be fixed in the next PTF.  Thank you!

Joanne Nguyen
ADSM Client Development



ADSM-L AT VM.MARIST DOT EDU on 09/01/98 03:45:53 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Error ANS4007E on restore using 3.1.05 Win95 32-bit client


Pete T.,

The problem occurs on my Windows 95 (4.00.950a) machine when using the
GUI to restore.  The test scenario is quite simple: I backup the
machine, delete a directory and all its files, then use the GUI to do a
restore.  All processing is local; Win NT and remote access is not
involved.  When I use the command line to do a restore, the error does
NOT occur on the new (dsmc restore \\mynode\c$\mydir\*) syntax nor the
old (dsmc restore c:\mydir\*) syntax.

Bob

===================================================

Can you append the exact syntax of the restore command you are issuing =

from the
command line client and
indicate what machine is doing the restore and what machine did the bac=

kup, as
well as whether both machines
are Win9x or NT ?

The output from the error log indicates that an access denied error is
occurring opening what I am assuming is
a remote file.

I make this assumption because of the fact that local UNC names are inv=

alid on
Win9x (they are valid on NT)
and should never be used by the client during either backup or restore.=



The ADSM client code should always use drive letters internally for loc=

al file
systems.

Just to illustrate the point, the directory c:\mydir on machine MYNODE =

could be
referenced either as c:\mydir
or \\MYNODE\c$\mydir on NT from any authorised machine (including the l=

ocal
machine MYNODE), but could
only be referenced as c:\testdir on the local machine on Win9x because,=

 as I
said, Win9x doesn't support local
UNC's.

I'm guessing that the problem you are seeing may be occurring because y=

ou don't
have write access to
\\mynode\C$\mydir from a remote machine (other than mynode) .

You can quickly verify this by issuing the following command directly f=

rom a
command prompt:

     mkdir \\mynode\c$\mydir

Usually on Win9x remote default UNC's can only be accessed if you are l=

ogged on
to an NT domain account (I don't  *think* that you can
create share level permissions on a default share name) which has acces=

s to the
resource.

In general, the new UNC support allows either drive letters or UNC's to=


specified on backup, and allows drive letters to be specified on
restore if the file is local or was backed up via a mapped drive letter=

.

Remote files backed up by specifying a UNC name directly will not be ac=

cessible
by the drive letter, they will only be accessible during restore  by
specifying the UNC (filespace) name used during backup.

Again, please post the restore syntax you are using and indicate whethe=

r or not
that the file is being restored to the same machine which
backed it up.

Thanks ....

Pete Tanenhaus, ADSM NT Client Development






<Prev in Thread] Current Thread [Next in Thread>