advisory file locks in linux - do they work?

[William Ahern]

On Mon, May 02, 2011 at 08:53:22PM -0600, Bob Proulx wrote:
> Jeff Gibson wrote:
<snip>
> > Instead I was hoping that it was possible for the internal-sftp
> > process to automatically lock incoming files.  As I have now
> > learned, OpenSSH/SFTP does not support this natively.  However, we
> > have had an internal developer add the functionality and so far it
> > seems to work.
> 
> Personally I have always been an advocate of writing the file off to
> the side in a temporary file and then renaming it into place.  That
> doesn't need a lockfile.  If you are hacking on the code to add
> cooperative file semaphores then you might consider writing to a
> temporary file and renaming it instead.  Since rename(2) is atomic the
> file will either be the previous file or the next file.  (Although
> recently with the Linux filesystems this semantic has been changed.)

rename was always atomic. You must be referring to the brief episode where
ext4 wouldn't guarantee the ordering of writes viz-a-viz rename in the
transaction log. That is, the rename might be committed before any prior
writes, rather than rename acting as an implicit write barrier. You still
ended up with an atomic rename--the old file intact or gone--but the new
file may not be whole after a crash even if the rename succeeded.

The defaults were quickly reverted to the expected behavior after raucous
protest. But to be completely safe according to a strict interpretation of
POSIX, fdatasync() or, if unavailable, fsync() should be issued _before_ the
rename. That defeats the use of rename as a cheap transaction primitive, and
that's why the behavior was reverted.