From: Jerry Peters on
unruh <unruh(a)wormhole.physics.ubc.ca> wrote:
> On 2010-02-02, Douglas Mayne <invalid(a)invalid.com> wrote:
>> On Mon, 01 Feb 2010 15:08:04 -0800, jinzishuai(a)gmail.com wrote:
>>
>>> Hi there,
>>>
>>> I am wondering if serious problem could happen if I copy a file that is
>>> actively being written to.
>>> I guess some file corruption might happen, right?
>>>
>> My _guess_ is that any "corruption" would show up as a failed backup
>> attempt. The original file is hopefully locked by its owner for exclusive
>> write access; thus, any external read attempt will not interfere with it.
>> However, the backup attempt will be "blurry" at best.
>
> File locking is something that depends totally on the program, and is a
> voluntary thing-- ie the reading program must check to see if the file
> is locked. ARAIK, there is no mechanism in Linux to lock a file so that
> nothing else can read it.

Actually there is, see man fcntl:

Mandatory locks are enforced for all processes. If a process tries to
perform an incompatible access (e.g., read(2) or write(2)) on a file
region that has an incompatible mandatory lock, then the result depends
upon whether the O_NONBLOCK flag is enabled for its open file descrip-
tion. If the O_NONBLOCK flag is not enabled, then system call is
blocked until the lock is removed or converted to a mode that is com-
patible with the access. If the O_NONBLOCK flag is enabled, then the
system call fails with the error EAGAIN or EWOULDBLOCK.

To make use of mandatory locks, mandatory locking must be enabled both
on the file system that contains the file to be locked, and on the file
itself. Mandatory locking is enabled on a file system using the "-o
mand" option to mount(8), or the MS_MANDLOCK flag for mount(2). Manda-
tory locking is enabled on a file by disabling group execute permission
on the file and enabling the set-group-ID permission bit (see chmod(1)
and chmod(2)).

The Linux implementation of mandatory locking is unreliable. See BUGS
below.

Of course this still requires that the writing program use fcntl lock.


Jerry
From: Douglas Mayne on
On Tue, 02 Feb 2010 22:30:29 +0000, unruh wrote:

> On 2010-02-02, Douglas Mayne <invalid(a)invalid.com> wrote:
>> On Mon, 01 Feb 2010 15:08:04 -0800, jinzishuai(a)gmail.com wrote:
>>
>>> Hi there,
>>>
>>> I am wondering if serious problem could happen if I copy a file that is
>>> actively being written to.
>>> I guess some file corruption might happen, right?
>>>
>> My _guess_ is that any "corruption" would show up as a failed backup
>> attempt. The original file is hopefully locked by its owner for exclusive
>> write access; thus, any external read attempt will not interfere with it.
>> However, the backup attempt will be "blurry" at best.
>
> File locking is something that depends totally on the program, and is a
> voluntary thing-- ie the reading program must check to see if the file
> is locked. ARAIK, there is no mechanism in Linux to lock a file so that
> nothing else can read it.
>
Thanks for the correction. I see now that the *nix permission model does
not include flags for locks. _Services_ which run on top of *nix which
want file locking (such as Samba), are what give the impression that locks
are implemented natively, when they are not.

--
Douglas Mayne


From: Chris Davies on
Douglas Mayne <doug(a)localhost.localnet> wrote:
> Thanks for the correction. I see now that the *nix permission model does
> not include flags for locks.

You're looking in the wrong place. *nix-based systems /do/ provide
locking, but it's rarely anything to do with permissions. See flock(1),
flock(2), and lockf(3) for the relevant documentation.

Chris
From: unruh on
On 2010-02-05, Chris Davies <chris-usenet(a)roaima.co.uk> wrote:
> Douglas Mayne <doug(a)localhost.localnet> wrote:
>> Thanks for the correction. I see now that the *nix permission model does
>> not include flags for locks.
>
> You're looking in the wrong place. *nix-based systems /do/ provide
> locking, but it's rarely anything to do with permissions. See flock(1),
> flock(2), and lockf(3) for the relevant documentation.
>
> Chris

man 2 flock
flock - apply or remove an advisory lock on an open file
....
flock() places advisory locks only; given suitable permissions on a file, a
process is free to ignore the use of flock() and perform I/O on the file.


From: despen on
"jinzishuai(a)gmail.com" <jinzishuai(a)gmail.com> writes:

> Hi there,
>
> I am wondering if serious problem could happen if I copy a file that
> is actively being written to.
> I guess some file corruption might happen, right?

Wrong.

Most files are written without locking.
If you are familiar with using the command:

tail -f

you'd know that reading a file as it's being written
causes no problems.

> More specifically, I am dealing with the snapshot of a qcow2 file.
> # qemu-img snapshot -c snap base.qcow2
> # cp base.qcow2 snap.qcow2
> # qemu-img snapshot -a snap snap.qcow2
> Do you think I will get an image snap.qcow2 that is completely
> consistent with the base.qcow2 image at the time when the snapshot is
> taken?

Some buffering will take place.

> For my case, it is OK if new information written to the disk after
> snapshot taken is lost or corrupted since all I want to copy is the
> backed up content. But would this copy during write process actually
> mess up the whole file and make it even un-readable?

Sounds like you might want to be using the syslog facilities?

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: nice bandwidth usage
Next: unexplained bianry "diff"