Thanks for the input. I'll give that a go. David
On Wed, Jan 20, 2016 at 8:58 PM, Luca Toscano <toscano.l...@gmail.com> wrote: > > > 2016-01-21 1:55 GMT+01:00 Yann Ylavic <ylavic....@gmail.com>: > >> On Wed, Jan 20, 2016 at 9:36 PM, David Rush <david.r...@wyo.gov> wrote: >> >> > What happens if it's updated (re-created) at the same instant that it's >> > being requested? >> >> This should be handled carefuly, the updater and the server should not >> race on the content of the file but on the file (inode) itself. >> >> You could first create the new file with an extension (e.g. ".tmp") >> and then rename it to the served file using "mv -f servedfile.tmp >> servedfile", which is usually atomic on Unixes (at least Linux and >> BSDs afaict). >> > > +1 > > The only issue that I can think of are slow clients requesting the content > of "servedfile" at some point X in time, finishing to receive it from httpd > at say X+4, meanwhile the new "servedfile" is created at X+2 (so the slow > client should get the correct content without any glitch/error/etc..). > > With Yann's suggestion the slow client will keep receiving the right > content even after the move from servedfile.tmp (new file) to servedfile > because a file descriptor opened to the old servedfile's inode (held by > httpd) will prevent the kernel to mark it as garbage (this of course on > Unixes where the move is atomic and the kernel honors inodes in that way). > New clients will get correctly the new content meanwhile the slow/unlucky > ones won't experience any inconsistency. > > Luca > > > > > > -- E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties.
