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