Quick file locking
in [Unix Programming]
|
From: Danmath on 10 Aug 2010 21:39 On 10 ago, 20:32, Rick Jones <rick.jon...(a)hp.com> wrote: > 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. As far as I know O_EXCL is for creating files with O_CREAT.
From: William Ahern on 10 Aug 2010 22:43 Rick Jones <rick.jones2(a)hp.com> wrote: > David Schwartz <davids(a)webmaster.com> wrote: > > On Aug 10, 12:05?pm, Danmath <danmat...(a)gmail.com> wrote: > > > Is there any chance a network transfer may work by opening and > > > closing the file more than once? > > Who knows? A 'network transfer' can do anything it wants to. > One example could be an FTP "restart" which, if my wetware DIMM memory > is working correctly, would allow one to "restart" a file transfer > from a given byte offset. > 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. Perhaps you're thinking of O_EXLOCK, which AFAIK is a BSDism. O_EXCL has nothing to do with locking, except when concoting a "dot" lock file system.
From: David Schwartz on 11 Aug 2010 03:39 On Aug 10, 4:32 pm, John Gordon <gor...(a)panix.com> wrote: > I thought of that, but if the two directories are on different filesystems > then mv isnt necessarily atomic, right? You can use rename instead. Create the file with a '.tmp' on the end and then rename it when it's finished. DS
From: David Schwartz on 11 Aug 2010 03:42 On Aug 10, 6:13 pm, Danmath <danmat...(a)gmail.com> wrote: > 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. That won't solve your problem, since another application can open the file for write a split second after you open it. > Opening the file > in a mode that will assure (if open succeeded) that the file isn't > being written to the > moment is much more straightforward than looping checking modification > times, > file changes, or whatever. What happens if another process opens the file right after you and modifies it before you get a chance to look at it? > Taking into account the closing and > reopening of the file > is not feasible as there seems to be no way around that without any > collaboration > between applications and I don't think it's likely enough. What I think you're missing is that cooperation is fundamentally required for this to work. There is simply no way in principle for your application to know when it should look at the file absent cooperation. DS
From: Nicolas George on 11 Aug 2010 04:14
John Gordon wrote in message <i3snim$6u2$1(a)reader1.panix.com>: >> Petter still: create and the fill in a "tmp" directory and then move it to >> the target directory. > I thought of that, but if the two directories are on different filesystems > then mv isnt necessarily atomic, right? I did not write "the /tmp directory" but "*a* "tmp" directory": I did not mean the system, world-writeable, /tmp directory, but a directory created within the application's worktree, dedicated to holding temporary files before they are renamed to other directories, and with adapter permissions. The sysadmin would be pretty stupid to put it on another filesystem. |