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-08-31 12:33:55

On 31 Aug 2015 at 12:28, Vladimir Prus wrote:

> For example, here are use cases I have at the moment
> 
> - Detect when files are added in a directory, compute their SHA1 checksum,
>    and notify my other code. Needs to use opportunistic locking on Windows
>    to make sure the computed checksum actually matches the final state of
>    the file.

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 is not going to provide some API for Windows-specific 
facilities. If you want that, use the Windows API. It does abstract 
out, where it can, platform differences such that AFIO on POSIX can 
work smoothly with AFIO on Windows over a networked drive using 
workaround filesystem based IPC.

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.

> - Write content X to a file F, but only if the file content did not change
>    since a change to that file was reported to me.

I would imagine tools other than AFIO would be more appropriate here. 
For example, Boost.Filesystem.

> and that starts with "I should emphasise once again that the advisory locking code is riddled with bugs",
> and has a code example with not a lot of comments, several "if (1)" and "#if 0" statements, and
> 
> 	// **** WARNING UNSUPPORTED UNDOCUMENTED API DO NOT USE IN YOUR CODE ****
> 
> remarks. Again, the fundamental design and engine might be sound, but it's impossible to
> say whether the library solve any practical problems.

That section is very useful for people comparing different locking 
strategies which is why I left it in there, even though admittedly 
the byte range locking support in AFIO is a work in progress.

Niall

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