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

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-08-31 13:47:49

On 31-Aug-15 7:33 PM, Niall Douglas wrote:
> 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.

Could you clarify that? File locking, on Windows, that is incompatible
with all other Windows programs, does not seem like a useful like locking
to me.

> 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.

I don't request a Windows-specific functionality per se, I'm looking for
a portable way to do a fairly standard filesystem operation that uses
the best mechanism on each platform. On POSIX, checksum computation
might coordinate with a filesystem watcher to detect writes by other
programs.

> 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.

Sorry, are you saying that AFIO cannot work if other programs are touching
the same files/directories? How that is potentially useful? If I control
all parties that write to a particular tree, I can use either boost.interprocess,
or boost.thread, to avoid all and every conflict at the filesystem locking.

>> - 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.

Possibly, thought I'd generally prefer async operations.

>> 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.

If there are such people, it's great. However, lacking any comments or structure, this example
is fairly incomprehensible wall of text.

- Volodya