id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
1972	boost::filesystem::remove() throws on self referenced symlinks	dizzy@…	Beman Dawes	"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).

However, I do think that bfs::remove(""sym"") throwing for the same reason 
(because it calls upon bfs::exists()) is the wrong thing to do. The source 
around bfs::remove() implementation even try to solve the issue of ""dangling 
symlinks"" as they call it by having an exception in case bfs::exists returns 
false and the target path points to a dangling symlink and still tries to 
remove it. Unfortunetly, exists will throw in my example of a symlink (not 
even dangling technically speaking :) ) even tho a remove on that kind of 
symlink should work just fine (it does work in shell or just doing 
std::remove()).

If boost::exists is going to be left in place to throw for those ""valid"" symlinks (because exists is suposed to try to dereference symlinks and dereferencing such a recursive symlink is always an error) then the only solution I see is to not use exists at all. Because I also found that remove and remove_all are fairly inefficient regarding repetitive calls fo stat/lstat on the same path I've created the attached patch that fixes the reported problem and would be more efficient ""system call"" wise.

I am using Linux and ext3 filesystem tho in theory it should perform the same on any symlink supporting platform (since symlinks are just containers of strings as defined by POSIX and if you try to dereference a self referencing symlink you should always get an error different than ENOENT and others for which exists() does not throw).
"	Bugs	closed	Boost 1.36.0	filesystem	Boost 1.35.0	Problem	fixed