Boost logo

Boost :

From: dizzy (dizzy_at_[hidden])
Date: 2008-05-30 09:22:57


On Friday 30 May 2008 15:11:04 Beman Dawes wrote:
> dizzy wrote:
> > Hello
> >
> > If one creates a symlink like this "ln -s sym sym" (to itself symlink),
> > bfs::exists("sym") will throw because the documentation defines it to do
> > so (and I have nothing against it doing so, although in my programs
> > because of this I am forced to just use "lstat()" and I can't replace
> > using "lstat()" to check if something exists with bfs::exists).
>
> Interesting! That's a case I never considered.

Yeah, we stumbled on it by accident as it appears one of the users of the
software had such a thing :) Either way it is something very possible on
probably any POSIX system.

> > If so, I should put it in the tracker?
>
> Yes, please do.
>
> Please mention what operating system you are using. I assume it is
> Linux, but it always helps to know for sure with filesystem issues.

I have reported it, thanks for your answer. I thought of another thing too,
maybe besides "exists(path)" there should be a "symlink_exists(path)"
(basically what symlink_status() is to status()), instead of doing status()
as exists() does, symlink_exists() could do symlink_status() and check if a
symlink OR a another file exists. Then in any code where I need to check if
something exists that's possibly a symlink (that resolves correctly or not) I
could use symlink_exists().

remove/remove_all are other examples that instead of exists() could use this
new symlink_exists().

The only problem I see with the symlink_exists() is that the old filesystem
API had something named somewhat similar that was used instead of the
current "is_symlink()", I'm speaking about the
deprecated "symbolic_link_exists()". For people used to
it, "symlink_exists()" with different semantics might confuse them (tho it
should not break existent code that still uses "symbolic_link_exists" of
course).

What do you think?

-- 
Mihai RUSU					Email: dizzy_at_[hidden]
			"Linux is obsolete" -- AST

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk