Re: [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-09-01 20:09:45

On 1 Sep 2015 at 11:39, Gavin Lambert wrote:

> On 1/09/2015 04:33, Niall Douglas wrote:
> > I would doubt that AFIO will ever be useful for this situation. The
> > way in which it will lock byte ranges is incompatible with all other
> > Windows programs in order to achieve POSIX byte range locking
> > semantics (and therefore compatibility with AFIO's running on NFS or
> > CIFS). It is also, deliberately, incompatible with other programs
> > doing POSIX byte range locking too in order to prevent unexpected
> > interactions.
> [...]
> > AFIO combined with anything not speaking AFIO is not supported, nor
> > will be. You will probably find this unreasonable and not useful, but
> > such are the differences between the platforms in file system any
> > additional abstraction is not practically useful.
> 
> Like others, this troubles me.
> 
> Do you mean that when you perform AFIO byte-locking the files will 
> appear completely locked to non-AFIO applications?  Or that they will 
> appear completely unlocked?  Or that it is unspecified (perhaps 
> dependent on file location or platform)?

Completely unlocked to other applications. This lets you add any byte 
range locks using native APIs yourself manually in addition to AFIO's 
byte range locks. AFIO doesn't involve itself at all in byte range 
locks to other applications.

> Either of the last two would be deal-breakers, I think -- the first 
> might be tolerable in some cases but could limit usability.

If you look into the terrible and awful world of byte range locking 
on POSIX especially across network shares, you will instantly 
understand how there can be no other way.

Windows has a very well designed and thought through byte range 
locking system which performs very well to boot. However, it's 
mandatory not advisory, and AFIO cannot use the usual sign inversion 
trick used to turn mandatory into advisory locks on Windows because 
unfortunately POSIX byte range locks stupidly use a *signed* range 
which lops off the top bit.

And those are just the fundamentals. It gets a lot, lot worse on 
POSIX. There are entire articles written on this, and the poor Samba 
team are probably the world experts and even *they* haven't entirely 
solved the problem after more than a decade of flogging that horse.

If you need easy interop with other applications, simply use a lock 
file instead of range locking. Those work everywhere with everything 
without nasty surprises.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/