Re: [boost] [filesystem] symbolic_link_exists naming AND is_file

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-03-20 20:29:13

At 09:15 PM 3/19/2005, Jeff Garland wrote:

 >I'm writing a small program with filesystem and I needed to check for
 >symbolic links so I can avoid processing them.  I noticed the
 >symbolic_link_exists method and, like all good programmers, didn't read
 >the docs b/c I was sure it didn't do what I needed.  So I set about 
writing
 >a function that would and when I looked at the filesystem implementation 
I
 >realized I was wrong. I was thinking that symbolic_link_exits would check
 >that a symbolic link points to a valid file -- essentially following the
 >symlink.  Any reason why this funtion isn't called is_symlink to match 
the
 >is_directory call?

Here is the rationale given in the documentation at 
http://www.boost.org/libs/filesystem/doc/operations.htm#symbolic_link_exists

    Rationale: The function does not throw if ph is not present, and is
    accordingly named symbolic_link_exists rather than is_symbolic_link.
    Non-throwing behavior permits testing for all four possible conditions:

    * ph not present: !exists(ph) && !symbolic_link_exists(ph)
    * ph present and is not a symbolic link: exists(ph)
      && !symbolic_link_exists(ph)
    * ph present and is a symbolic link to a non-existent file or
      directory: !exists(ph) && symbolic_link_exists(ph)
    * ph present and is a symbolic link to an existing file or
      directory: exists(ph) && symbolic_link_exists(ph)

In other words, the current naming and semantics (not throwing), is both 
logically consistent and allows all possible conditions to be tested for.

I guess you could make an argument that the name is_symbolic_link() with 
non-throwing semantics would be more satisfying in some sense even if less 
logically consistent.

 >Also, in the code I'm writing I need to only process regular files.  So 
it
 >would be nice to write:
 >
 >if (is_file(my_path)) {
 >
 >  //do stuff
 >}
 >
 >where is_file is defined as follows:
 >// equivalent of if (-d path) in perl
 >// returns !is_directory(p) && !is_symlink(p);
 >bool is_file(fs::path p);
 >
 >Or maybe it could be is_regular_file or is_plain_file if we want to be
 >verbose.  Seems like this would be handy to have in the filesystem 
lib.  I
 >can probably be talked into supplying patches ;-)
 >
 >Thoughts?

The original rationale for not supplying is_file() was (1) concern over 
devices, which are treated as files in some operating systems, but not in 
other operating systems, and (2) minimalism, since it was trivial to code 
!directory() directly.

That was before the issue of symbolic links came up, so it might be worth 
revisiting. But why do you add "&& !is_symlink(p)"? My expectation for a 
function named is_file() would be that it be "deep" and ignore the fact 
that the file was reached via a symbolic_link. In other works, the 
implementation would just be

   {
     return !directory(ph);  // note that this may throw
   }

--Beman