boost::filesystem -- handling dead symlinks

[Matthias Kaeppler]

Hello,

I wonder if there is any means of telling
boost::filesystem::directory_iterator to skip broken symlinks. It's sort
of an annoyance working with them, since operations like is_directory
will throw when invoked on a broken symlink.
I am keeping a vector of boost::filesystem::pathS, and as soon as I
operate on a broken symlink, an exception will be thrown. I do catch it,
but that doesn't really help since the program will return from the
method where the exception was thrown. I would find it much more
convenient to simply skip these broken files, instead of jumping out of
the procedure (IMO it's not even exceptional behavior, dead symlinks are
pretty common).

Any idea what I can do about this?

[me22]

On Sun, 20 Feb 2005 11:28:23 +0100, Matthias Kaeppler

Post by Matthias Kaeppler
I wonder if there is any means of telling
boost::filesystem::directory_iterator to skip broken symlinks. It's sort
of an annoyance working with them, since operations like is_directory
will throw when invoked on a broken symlink.
I am keeping a vector of boost::filesystem::pathS, and as soon as I
operate on a broken symlink, an exception will be thrown. I do catch it,
but that doesn't really help since the program will return from the
method where the exception was thrown. I would find it much more
convenient to simply skip these broken files, instead of jumping out of
the procedure (IMO it's not even exceptional behavior, dead symlinks are
pretty common).

http://boost.org/libs/filesystem/doc/operations.htm#symbolic_link_exists says:
* 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)

Or, less elegantly, you could always catch the exception in the procedure.

Hope that helps,
- Scott McMurray
( Disclaimer: I'm new here )

[Matthias Kaeppler]

Post by me22
* 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)

Aaah, thanks a ton :)
Don't know how I could miss it.

Regards,
Matthias

[Ben Hutchings]

Post by me22
On Sun, 20 Feb 2005 11:28:23 +0100, Matthias Kaeppler

Post by Matthias Kaeppler
I wonder if there is any means of telling
boost::filesystem::directory_iterator to skip broken symlinks. It's sort
of an annoyance working with them, since operations like is_directory
will throw when invoked on a broken symlink.
I am keeping a vector of boost::filesystem::pathS, and as soon as I
operate on a broken symlink, an exception will be thrown. I do catch it,
but that doesn't really help since the program will return from the
method where the exception was thrown. I would find it much more
convenient to simply skip these broken files, instead of jumping out of
the procedure (IMO it's not even exceptional behavior, dead symlinks are
pretty common).

* 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)
Or, less elegantly, you could always catch the exception in the procedure.

Since the filesystem is normally shared with other processes which may
change it at any time, you should be prepared for file operations to
fail even if you check in advance that they should work. So checking in
advance cannot substitute for exception-handling; it's extra programming
effort and may actually be slower than handling the occasional exception.

Ben.

[Matthias Kaeppler]

Post by Ben Hutchings

Post by me22
Or, less elegantly, you could always catch the exception in the procedure.

Since the filesystem is normally shared with other processes which may
change it at any time, you should be prepared for file operations to
fail even if you check in advance that they should work. So checking in
advance cannot substitute for exception-handling; it's extra programming
effort and may actually be slower than handling the occasional exception.
Ben.

I do both. However, for the problem I was describing, it's already too
late when the exception is caught, because application flow terminates
for a (IMO) minor reason at a point where I can't go back.
But of course, I still catch filesystem_errors on several occasions.