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

Number   :  3749
Date     :  2003-02-18
Author   :  Kan Yabumoto
Subject  :  /M vs /BI
Size(KB) :  2


This message is a reply to Tom, but I rename the subject.

I believe that you are (wrongly) assuming that the /BI switch
excludes newly added/created files in the source directory.
The truth is that /BI by itself excludes files that are
identical to their counterpart in the source directory
(by checking the filesize and filetime). Like many other
file-selection switches, the /BI operates in the principle
of exclusion (by excluding unchanged files). That means
/BI includes "brand new" files.

If you want to make XXCOPY to exclude the "brand new" files
(the files that are not present in the destination), the switch
to use is /U which selects only the files that are common
to both the source and the destination.

Let me compare /M and /BI on their merits.

The only case which /BI misses but /M can function as intended
is when an application program modifies a portion (or the
whole thing) of a file and deliberately restores the filetime
to be what it was before the change, as long as the filesize
is kept exactly the same, the /BI switch will not be able to
tell that the file has undergone the change. But, this is
a very extreme case which is very unlikely to happen. It is
purely academic. Moreover, if you worry about such a bizarre
case as the basis for the preference of /M over /BI, let me
provide an opposite case which is at least equally plausible:
when an application program modifies (or rewrites) a file
without even attempting to keep the file time or the file size
(a common file-overwrite operation), yet it resets the archive
bit at the end of the file-revision operation, a backup
scheme which relies on the archive bit (/A or /M) will miserably
miss the overwritten file.

So, short of comparing the source and the destination files
byte-by-byte, you will never achieve a perfect "incremental
backup". Since the whole idea of an "incremental backup"
is to save time by skipping "the unchanged" files, to go
and perform a "byte-by-byte" comparison simply defeats the
original motivation. Moreover, let me point out that
an "incremental backup" of a byte-by-byte comparison that
is followed by a possible (but extremely rare) rewrite of
the file (due to a byte-mismatch) is much less efficient than
a straight unconditional file copy operation. That is,
if you don't take any chances that you may miss a file
due to the "incompleteness" of the identity checking,
you should not even think about an "incremental" backup.
You better perform a full "unconditional" backup in that
case.

I have not seen a convincing argument which favors /M over /BI.

Kan Yabumoto

===================================================================
At 2003-02-18 09:30, you wrote:
>Kan,
>
>The problem I have is "BI" won't backup files or directories that
>have been added or moved to the backup directory. The only way I
>know to backup added files is the archive attribute.
>
>Is there another switch I'm missing?
>
>Thanks,
>
>Tom Albright



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