Subject: Re: [SG16-Unicode] filesystem::path_view::compare()
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-08-25 06:50:28
On 25/08/2019 04:31, Lyberta wrote:
>> 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.
SG16 list run by email@example.com