Quick file locking
in [Unix Programming]
|
From: Nicolas George on 10 Aug 2010 18:01 John Gordon wrote in message <i3s995$qkd$1(a)reader1.panix.com>: > 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". Petter still: create and the fill in a "tmp" directory and then move it to the target directory.
From: David Schwartz on 10 Aug 2010 18:15 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. > 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? I don't think it's possible without at least some cooperation. You can try copying the file, waiting a few seconds, and then checking to see if the file is unchanged. > 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? How will that help you? You are now reading a file that is nonsensical because it is only partially updated. DS
From: John Gordon on 10 Aug 2010 19:32 In <4c61cc44$0$683$426a34cc(a)news.free.fr> Nicolas George <nicolas$george(a)salle-s.org> writes: > John Gordon wrote in message <i3s995$qkd$1(a)reader1.panix.com>: > > 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". > 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? -- 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"
From: Rick Jones on 10 Aug 2010 19:32 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. rick jones -- denial, anger, bargaining, depression, acceptance, rebirth... where do you want to be today? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Danmath on 10 Aug 2010 21:13
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. 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. 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. |