From: Danmath on
I want to read a file and be sure that no other application is writing
into that file at the same time. Is fopen() using 'r+' mode enough?
and open() using _EXLOCK? I can't control if the other applications
use any locking method or not, so it has to work no matter in what way
other applications open the file. The file may be in the middle of a
network transition at the moment I want to open it. It would be enough
to know how to determine if another application is already writing to
the file when I want to open it, in this particular case I know the
file is not going to be written to after it was created and closed
once, although I would be interested in knowing how to keep other
applications (not programmed by me) from opening the file once I
opened it. Apparently flock() is only used for cooperative locking
scenarios, so I can't use that, but I haven't read any comment about
_ELOCK o r+ being non cooperative safe either.

From: David Schwartz on
On Aug 9, 6:44 pm, Danmath <danmat...(a)gmail.com> wrote:

> I want to read a file and be sure that no other application is writing
> into that file at the same time. Is fopen() using 'r+' mode enough?
> and open() using _EXLOCK? I can't control if the other applications
> use any locking method or not, so it has to work no matter in what way
> other applications open the file. The file may be in the middle of a
> network transition at the moment I want to open it. It would be enough
> to know how to determine if another application is already writing to
> the file when I want to open it, in this particular case I know the
> file is not going to be written to after it was created and closed
> once, although I would be interested in knowing how to keep other
> applications (not programmed by me) from opening the file once I
> opened it. Apparently flock() is only used for cooperative locking
> scenarios, so I can't use that, but I haven't read any comment about
> _ELOCK o r+ being non cooperative safe either.

There is no way, even in principle, to do this without cooperation of
other processes. What if a process did this:

1) Open the file.
2) Read it.
3) Overwrite half of it.
4) Close the file.
5) Re-open the file.
6) Overwrite the other half.

How could you possibly tell that step 4 was not the last step?

Cooperating processes have to actually be coded to cooperate.

DS
From: Nicolas George on
Danmath wrote in message
<544dcbf6-fb1e-4acb-94cc-18af1e071673(a)x25g2000yqj.googlegroups.com>:
> I want to read a file and be sure that no other application is writing
> into that file at the same time.

http://www.opengroup.org/onlinepubs/9699919799/utilities/chmod.html

Look for "mandatory locking". But this highly non-portable and seldom
implemented. For example:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/mandatory-locking.txt;h=0979d1d2ca8bb94b21d15f7a0c193ac7ce9f4f9f;hb=HEAD
(short extract: "The Linux implementation is prey to [...] race conditions
which in practice make it not dependable")

(By the way, this text explains quite good how it is supposed to work.)
From: Danmath on
On 10 ago, 05:03, David Schwartz <dav...(a)webmaster.com> wrote:
> On Aug 9, 6:44 pm, Danmath <danmat...(a)gmail.com> wrote:
>
> > I want to read a file and be sure that no other application is writing
> > into that file at the same time. Is fopen() using 'r+' mode enough?
> > and open() using _EXLOCK? I can't control if the other applications
> > use any locking method or not, so it has to work no matter in what way
> > other applications open the file. The file may be in the middle of a
> > network transition at the moment I want to open it. It would be enough
> > to know how to determine if another application is already writing to
> > the file when I want to open it, in this particular case I know the
> > file is not going to be written to after it was created and closed
> > once, although I would be interested in knowing how to keep other
> > applications (not programmed by me) from opening the file once I
> > opened it. Apparently flock() is only used for cooperative locking
> > scenarios, so I can't use that, but I haven't read any comment about
> > _ELOCK o r+ being non cooperative safe either.
>
> There is no way, even in principle, to do this without cooperation of
> other processes. What if a process did this:
>
> 1) Open the file.
> 2) Read it.
> 3) Overwrite half of it.
> 4) Close the file.
> 5) Re-open the file.
> 6) Overwrite the other half.
>
> How could you possibly tell that step 4 was not the last step?
>
> Cooperating processes have to actually be coded to cooperate.
>
> DS

Is there any chance a network transfer may work by opening and
closing the file more than once? The only way files are supposed to
arrive to the input directory for my application is by network trasfer
or being moved by scripts using mv. Is it possible to achieve what I
want in this case?

In the case you describe, if I open the file with 'r+' using fopen()
or
_EXLOCK using open() after step 4, shouldn't the other process get an
error
in step 5?
From: John Gordon on
In <a180051a-b3b4-4ec3-bf83-6bc6d8ab5db1(a)y3g2000vbm.googlegroups.com> Danmath <danmath06(a)gmail.com> writes:

> The only way files are supposed to arrive to the input directory for my
> application is by network trasfer or being moved by scripts using mv. Is
> it possible to achieve what I want in this case?

Do you have control over the program which transfers or mv's the files?
If so, a simple solution would be to give the files a special name such
as "filename.INPROGRESS" while they are still being written, and when the
transfer is finished rename the file to "filename.COMPLETE". Then you
need only look for filenames with a *.COMPLETE suffix and never worry
about locking at all, because renaming a file is atomic.

If you don't have control over the arrival of files, then it's a much
stickier problem.

--
John Gordon A is for Amy, who fell down the stairs
gordon(a)panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"