This is a critical issue, I think. If the file is open and being modified,
then if at time "t0" you start sending file through rsync, at t1 rsync
copied say block-2, at t3 while it copying block-10 (say), block-2 get
modified and whole file end up with a corrupted file. Thus this file is
inconsistent, right ? And we won't notice that the file being send is
inconsistent. Some people may like to use backup option or writing a good
script to avoid open files using utility "lsof".
-Sanjeev
-----Original Message-----
From: Martin Pool [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2000 8:48 PM
To: Bennett Todd
Cc: Richard Crane; [EMAIL PROTECTED]
Subject: Re: action with open/modified files
On 12 Oct 2000, Bennett Todd <[EMAIL PROTECTED]> wrote:
> 2000-10-12-15:05:55 Richard Crane:
> > What does rsync do when copying a file that may be modified while it is
> > being read?
> But if files are being modified while they are being read, rsync can
> get badly confused, at least in principle. Best to avoid stressing
> it.
Bennett's explanation is very good.
There's not much rsync can do beyond this, as neither Unix nor NT have
ACID-transactional filesystems, and so we can't ask the OS to give us
a consistent view of the file while we synchronize it.
However, you can do this yourself with a wrapper appropriate to the
situation. For example, you might copy the file to a temporary
directory before you rsync it, or temporarily suspend the program
writing to it. The common case of append-only logfiles should work
reasonably well: rsync will just copy more or less of it towards the
end.
> Now whether rsync can be actually provoked into e.g. dumping core,
> or erasing everything in sight, or siezing up your computer in a
> spasm that makes it catch fire and burn your machine room down, I
> don't know; it could be that all possible outcomes end up only
> corrupting the file that's modified during the sync.
Of course we're interested to hear of *any* situation which will
actually make it crash. (Preferably reproducible, and preferably on
Un*x.)
--
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
