RE: [Boost-Users] Boost::Filesystem: Directory iterator and dangling links
You wrote: <snip>
In the case of dangling links I obtain a not_found_error. This seems to be a contradiction. First I find something (and obtain an iterator) and without any interference from outside is_directory() tells me it cannot find the object. The problem is that directory_iterator refers to the link whereas is_directory() and the following exception refer to the target (which is missing). <snip>
To make this consistent, then, maybe is_directory() and friends should be using lstat rather than stat on Unix. Is it desirable that links be resolved? I suppose it is if the iterator is being used to walk a whole tree - but not if it's being used to list a single directory. Perhaps there is a need to include explicit support for links in the API. Windows has supported them since 2000, so they aren't just a Unix thing now.
At 06:36 AM 4/22/2003, Ben Hutchings wrote:
...Is it desirable that links be resolved? I suppose it is if the iterator is being used to walk a whole tree - but not if it's being used to list a single directory.
Here is the rationale for resolving links: if links are resolved, then applications desiring resolution work, and by querying attributes, applications not desiring resolution also work. If links are ignored, then there is no way to for applications desiring resolution to work.
Perhaps there is a need to include explicit support for links in the API. Windows has supported them since 2000, so they aren't just a Unix thing now.
Keep in mind that there are two forms of links - the simplest kind acts like a pointer, and like a pointer, can fail if the pointed to entry is removed. The other kind of link is more like a reference counted smart pointer, where the only way to access the entry is via the link. That provides much more disciplined link management, since the actual filesystem object never goes away as long as any links are present. It wouldn't surprise me if there were also some other kinds of links out there, with still different behavior. --Beman
participants (2)
-
Beman Dawes -
Ben Hutchings