ADSM-L

Error ANS4007E on restore using 3.1.05 Win95 32-bit client

1998-09-01 12:43:29
Subject: Error ANS4007E on restore using 3.1.05 Win95 32-bit client
From: Pete Tanenhaus <tanenhau AT US.IBM DOT COM>
Date: Tue, 1 Sep 1998 12:43:29 -0400
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 backup, 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 invalid 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 local 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 local
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 you 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 from a
command prompt:

     mkdir \\mynode\c$\mydir

Usually on Win9x remote default UNC's can only be accessed if you are logged on
to an NT domain account (I don't  *think* that you can
create share level permissions on a default share name) which has access 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 accessible
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 whether or not
that the file is being restored to the same machine which
backed it up.

Thanks ....

Pete Tanenhaus, ADSM NT Client Development


---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 09/01/98
1/98
11:29 AM ---------------------------


ADSM-L AT VM.MARIST DOT EDU on 09/01/98 08:06:00 AM
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.: Thanks for the very quick reply, but the problem actually
appears to be the opposite of what you say.  I'm having the problem
using the new level  5 client to restore from a backup taken by the same
(new level 5) client from a new (migrated to UNC naming convention)
filespace.  Even more strange is the fact that the new level 5 client
does NOT incur the error when restoring from the old filespace backed up
the level 2 client.  So, I'm still looking for answers here.  I plan to
run additional tests using the level 5 command line syntax, but I still
to need to know about the GUI since that is what our customers will be
using.  Thanks again Pete (or anyone else) for a quick answer here.

Bob Brazner

========= Original message thread follows ===========

Date:    Mon, 31 Aug 1998 22:50:07 -0400
From:    Pete Tanenhaus <tanenhau AT US.IBM DOT COM>
Subject: Error ANS4007E on restore using 3.1.05 Win95 32-bit client

I believe that there may be a bug restoring from older filespaces which
have
not been migrated
to the new UNC naming convention introduced in ptf 5.

Filespace names are automatically converted to the new UNC naming
convention
when accessed for
backup for the first time by the level 5 client.

The old filespace name is, however, left intact during restore.

I'm guessing that the problem you are seeing occurs because the restore
is
being done before the filespace name
has been migrated to the new naming convention.

Once the filespace name has been migrated to the new naming convention
the
problem should go away.

Can you try backing up a file up to this filespace and then try the
restore
again ?

Thanks .....

Pete Tanenhaus, ADSM NT Client Development
---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on
08/31/
08/31/
1/98
09:48 PM ---------------------------


ADSM-L AT VM.MARIST DOT EDU on 08/31/98 07:46:41 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


I receive the following error message (names changed to protect the
innocent) when using the new 3.1.05 Win95 32-bit client to restore a
single directory backed up by the 3.1.05 client.  However, the directory

does indeed get created and all the data seems to come back.

08/31/1998 18:13:12 CreateDirectory(): Win32 RC=5 .
08/31/1998 18:13:12 ANS4007E Error processing '\\mynode\c$\mydir':
access to the object is denied

When I use the new 3.1.05 client to restore the same directory from a
backup taken by the previous client (3.1.03), I do not receive any error

messages.

Can anyone explain the meaning of the *apparent* error message?



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