boost::filesystem -- handling dead symlinks
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? -- Matthias Kaeppler
On Sun, 20 Feb 2005 11:28:23 +0100, 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 )
me22 wrote:
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)
Aaah, thanks a ton :) Don't know how I could miss it. Regards, Matthias -- Matthias Kaeppler
me22 wrote:
On Sun, 20 Feb 2005 11:28:23 +0100, Matthias Kaeppler
wrote: 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.
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.
Ben Hutchings wrote:
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. -- Matthias Kaeppler
participants (3)
-
Ben Hutchings
-
Matthias Kaeppler
-
me22