[<<]Message[>>]    [<<]Author[>>]    [<<]Subject[>>]    [<<]Thread[>>]

Number   :  7769
Date     :  2004-04-26
Author   :  Garry Deane
Subject  :  Re: prevent deletion of file with clone
Size(KB) :  3


--- In xxcopy@yahoogroups.com, "ethoscjp"  wrote:
> Thanks Kan for the info
> 
> Believe someone recommended the /Clone switch a couple of
> years ago when I first started using xxcopy and saw it being
> used in the technical papers on the website. 
> 
> It has worked very well for our application but have found
> on rare occassions after having been tested and working
> across a network or WAN connection for sometime that
> something seems to halt the program either a system file
> incompatibilities due to updates and patches or loss of
> network connection that the destination files are then
> gone and the next time the batch file runs it then has
> to transfer all the data again, which can take hours due
> to the speed of the WAN connection and amount of data. 
> 
> We use it to create a duplicate local copy of files from
> a remote location so that users have local read only access
> to files and also act as a additional backup. I will now
> be using the /Backup switch and on a periodic basis add
> in the /ZY switch to remove any files in the destination
> that are no longer in the source. Does this seem like 
> a good idea?
> 
> If you can suggest a preferrable method I'm all ears as
> think the program is an excellent tool.

This can be quite a problem when doing a network based file
comparison. Basically the deletion operation relies on
examining the files in the destination and then looking to
see whether that same file also exists in the source. If
the remote source suddenly disappears because of a dropped
network connection, the corresponding file obviously also
appears to be absent. Unless the OS reports an error
condition which Kan could check, it would appear to be
no different to the connection still being alive but the
source file actually being absent. Either way, the
destination file will be deleted.

I can't think of any 100% safe scheme which would protect
against accidental file deletion on the destination where
the source is a remote PC and the connection to the source
might be lost.

You could add a /IP test to make sure that the
remote source exists before the operation commenced but that
still wouldn't protect against a connection being dropped
after the operation started.

You could use the archive bit to initially tag which files
should be deleted then examine how many files were tagged.
If the number is higher than expected, you could abort the
file deletion step but this would be hit and miss.

The safest way to protect against a dropped connection would
be to run the xxcopy command on the machine being backed up
with the source as a local drive and the destination as the
remote computer. This (almost) guarantees that the source
is available and if the connection to the remote destination
is lost, no files will be deleted.

Therefore rather than running xxcopy with a network source
address, you could use a program like sysinternal's PSEXEC
to run the xxcopy command on the remote PC so that the source
is a local drive. Similarly, you could use AT to schedule
the xxcopy command to run on the remote source PC.

Garry



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.