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
Could you clarify that? File locking, on Windows, that is incompatible
with all other Windows programs, does not seem like a useful like locking
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk