On 31 Aug 2015 at 20:47, Vladimir Prus 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.
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.
Firstly, the byte range locking isn't finished nor turned on in AFIO right now, so I may yet change my mind. However, right now if you specifically need local platform byte range locking, I think you need custom code using the native APIs to do that, and AFIO deliberately does not get in the way. Windows and POSIX byte range locking is fundamentally completely incompatible. No single API which is sane can do both in a performant way.
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.
I meant specifically byte range locking only. AFIO never locks byte ranges in the files other third party processes uses. It locks byte ranges in a hidden shadow file only which is managed by AFIO internally. AFIO on POSIX can talk to AFIO on Windows over networked drives using the hidden shadow file as a IPC channel.
- 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.
I would be very surprised if async gained you anything except extra maintenance costs. If, and only if, you very rarely open and close files and have a real async backend (i.e. currently Windows only) then you have a good change of seeing significant improved performance IF you restructure your filing system code to match how filing systems really work which means throwing out how most programmers write file system code. The resulting application will always be complex and non-trivial i.e. it's not worth the hassle for almost everybody. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/