Re: [Boost-Users] Boost::Filesystem: Directory iterator and dangling links

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-04-18 09:48:46

At 04:45 PM 4/14/2003, Peter Klotz wrote:

 >The following is a part of the directory_iterator documentation:
 >
 >"A path returned by dereferencing a directory_iterator is, if 
representing
 >a directory, suitable for.... If not representing a directory, the
 >dereferenced path is suitable for..."
 >
 >So I would assume that dereferencing a directory_iterator and using
 >is_directory() should always be possible.

For some operating systems, that isn't correct. For example, on Windows 2K 
(and presumably other Windows variants), certain files like the pagefile 
can't even be queried by is_directory() without an exception being thrown.

 > This is not the case for a dangling link.
 >
 >In the example below is_directory() throws an exception when a dangling
 >link is encountered.
 >
 >boost::filesystem::directory_iterator itDirEnd;
 >for (boost::filesystem::directory_iterator
 >itDir("/tmp");itDir!=itDirEnd;++itDir)
 >{
 >    if (boost::filesystem::is_directory(*itDir)) // throws an exception 
for
 >dangling links
 >        ;
 >}

Could you give a bit of background on the above? What operating system? 
Exactly what do you mean by "dangling link"? If your operating system has 
several kinds of links, which kind are you talking about?

 >Should the use of directory_iterator under certain circumstances force 
the
 >user to use the native operating system API?

Yes - in cases where there doesn't seem to be any way to abstract the 
operation into a portable function it is better to leave it for an 
operating system specific function.

 >Wouldn't it be more consistent to skip links altogether when iterating?

I'm not sure. Non-pathological links seem to work as expected, and 
operating systems often detect and report pathological cases as errors, 
which seems to me to be reasonable behavior. OTOH, links aren't an area 
that has received a lot of scrutiny, so it may be that some change is 
needed.

--Beman