On 25/08/2019 04:31, Lyberta wrote:
> Lyberta:
>> I'm thinking of abstraction where there is a virtual function call
>> overhead but not a syscall overhead for every comparison and where there
>> is still possible to compare paths to nonexistent files even when the
>> actual comparison algorithm is implementation defined.
>
> On the second thought, yes, a path component may be on exotic VFS that
> can't be known ahead of time. So there is a way to optimize for common
> cases like NTFS on Windows and EXT4 on Linux but no way to implement
> general case without calling the OS to do actual comparison every time.

As soon as one approaches a problem thinking in terms of filesystem
paths as a solution, it is almost always the case that program
correctness is no longer possible.

Simple solution: avoid filesystem paths wherever possible. Consider
absolute paths as an especially toxic code smell. Use alternatives.

llfio::file_handle::unique_id() returns a type which is Regular and
comparable. So don't put filesystem paths into an ordering (unless you
are treating them lexicographically as strings), put llfio::file_handle
into an ordering, using llfio::file_handle::unique_id() as the index.

The only caveat to this approach is the very low soft limit on open file
descriptor count in some POSIX implementations. This can be worked
around using a shared_ptr<llfio::path_handle> for the containing
directory and llfio::directory_entry to race free track leaf nodes. Then
your program will be capable of correctness, up to the path_handle.

Niall