From: Nicolas George on 11 Aug 2010 04:14 David Schwartz wrote in message <3d841fc6-c60e-4c4c-aa64-15a1f7ca3dbf(a)z30g2000prg.googlegroups.com>: > You can use rename instead. Create the file with a '.tmp' on the end > and then rename it when it's finished. Which means the program must check the filename extension. I like my solution better.
From: Richard Kettlewell on 11 Aug 2010 04:21 Rick Jones <rick.jones2(a)hp.com> writes: > IIRC, open()ing the file with O_EXCL will ensure that noone else has > the file open or will be able to open the file while you have it open, > but that does not address the open,mod,close;open,mod,close issue > already raised. All O_EXCL does is stop a file being opened if it already exists. It's a convenient primitive in constructing an advisory lock (provided the underlying filesystem isn't too stupid) but it does not ensure exclusive access to the file on its own. -- http://www.greenend.org.uk/rjk/
From: Rainer Weikusat on 11 Aug 2010 08:57 Danmath <danmath06(a)gmail.com> writes: > On 10 ago, 19:15, David Schwartz <dav...(a)webmaster.com> wrote: >> How will that help you? You are now reading a file that is nonsensical >> because it is only partially updated. >> >> DS > > I know, I just wanted to know if it would be blocked or not.To cut the > matter short, I'm only interested in a method that will assure that > another application doesn't have the file open in write mode in the > moment my application tries to open it. Ordinarily, considering that we are here in a UNIX(*) group, the answer should be: UNIX(*) file system semantics and Windows file system semantics differ in a very fundamental way. Windows applications are supposed to be actively fighting among themselves and the business of the kernel/ file system implementation is to stop them from actually harming each other. UNIX(*) applications are supposed to cooperate and the business of the kernel/ file system implementation is to enable and support this cooperation. At least on Linux, you could use a so-called 'lease', see fcntl(2) 'Leases' for details.
From: Scott Lurndal on 11 Aug 2010 13:29 Richard Kettlewell <rjk(a)greenend.org.uk> writes: >Rick Jones <rick.jones2(a)hp.com> writes: >> IIRC, open()ing the file with O_EXCL will ensure that noone else has >> the file open or will be able to open the file while you have it open, >> but that does not address the open,mod,close;open,mod,close issue >> already raised. > >All O_EXCL does is stop a file being opened if it already exists. s/opened/created/ scott
From: Richard Kettlewell on 11 Aug 2010 14:05
scott(a)slp53.sl.home (Scott Lurndal) writes: > Richard Kettlewell <rjk(a)greenend.org.uk> writes: >> Rick Jones <rick.jones2(a)hp.com> writes: >>> IIRC, open()ing the file with O_EXCL will ensure that noone else has >>> the file open or will be able to open the file while you have it >>> open, but that does not address the open,mod,close;open,mod,close >>> issue already raised. >> >>All O_EXCL does is stop a file being opened if it already exists. > > s/opened/created/ Not really. It's not like the file gets created a second time if it already exists and you didn't ask for O_EXCL. -- http://www.greenend.org.uk/rjk/ |