Re: Note from you attached below
Keith,
If you got a Data Unavailable on server, then that was an error passed back
from the server. It means either:
1) the file was temporarily involved in a reclamation operation
2) server encountered a read error
3) or the data was corrupted.
My guess is that the data for that folder (the access privileges) was
involved in the reclamation process (I assume you were restoring from
tape). You would never get the data unavailable error from any error on
the Mac file system.
It's true that we backup the Move&Rename folder by default. You can
exclude it in the ADSM Preferences file so that none of the files inside
it (if there are any) get backed up. However, we still backup the actual
folder entry, and the access privs associated with it. However it
doesn't cause any problems to restore it. The system usually doesn't
even care about it.
We do display invisible files, because you want to be able to backup/restore
them. Good example is the Icon file in a folder that changes the icon
for a folder. This is an invisible file which you want restored.
Hope this helps...
Brett Walker
------------------------------- Referenced Note ---------------------------
>Well, one of our consultants did a silly thing and found a slight
>Well, one of our consultants did a silly thing and found a slight
>problem in the process. Here's the case: If you boot a system from
>a floppy and then throw away all the file/folders on the hard disk,
>then do a restore for the entire volume. ADSM creates all the folders
>and just dies when it gets to the Move&Rename folder with a message
>along the lines of data not available (sorry, I fixed this one over the
>phone). If you mount any volume, the Move&Rename folder gets updated/
>rebuilt/whatever and the backup will proceed as it should. The
>consultant mailed someone at Apple named Mike Zachary about the problem
>and received the following reply. Thought it might be useful to
>better understand what happened in case anyone else runs across this.
>No idea how ADSM selects it's files, but it looks like picking up this
>one should be avoided.
>
>-----------------
>
>1) The "Move&Rename" folder (which is marked invisible) is created by Personal
> File Sharing and AppleShare as a temporary holding point for files during
> the execution of AppleShare File Protocol (AFP) "Move and Rename" calls.
> The "Move and Rename" call, as the name suggests, is used to move a file
> between folders and give it a different name in the destination folder.
> HFS only supports separate Move (with the same name) and Rename (in the
> same folder) calls.
>
> Since the file can't be renamed and then moved (there might be a name
> conflict with the new name in the source folder) and can't be moved and
> then renamed (there might be a conflict with the old name in the
> destination folder), the only way to correctly execute the call on an HFS
> volume is to do the following:
>
> 1) Move the file to the "<box><box><box>Move&Rename" folder.
> 2) Rename the file there to the new name.
> 3) Move the file to the destination directory.
>
> By the way, the <box><box><box> are the ASCII characters 0x01, 0x02, and
> 0x03, which generally don't have legitimate character representations in
> most fonts. We wanted to make sure this folder wouldn't be confused with
> user folders, so we gave it a name that would be hard to type.
>
>
> 2) The "Move&Rename" folder should always be empty, except in mid-operation,
> and is emptied at system startup (it also is deleted at system shutdown).
>
>
> 3) The "Move&Rename" folder should NOT be used by anyone or anything but
> AppleShare and Personal File Sharing. Also, Macintosh applications are
> not supposed to show invisible folders in SFGetfile or SFPutFile.
>
>
> Note: There is no way to prevent software from being able to see the
>"Move&Rename" folder or put files in it. AppleShare and Personal File Sharing
> absolutely require the "Move&Rename" folder.
>
> Copyright 1994, Apple Computer, Inc.
|
