[filesystem] convenience_test.cpp question
Hi, on studying the boost's files I found in convenience_test.cpp this statement: BOOST_CHECK( fs::extension("a/") == "." ); Why this? IMO it's not clear why this should be correct. This means that a leaf path has a file extension. On directory's view this is not equal to the current dir notation. Thanks, Olaf BTW, what about the support on hard- and softlinks mentioned in this list some times ago?
Olaf Peter wrote:
Hi,
on studying the boost's files I found in convenience_test.cpp this statement:
BOOST_CHECK( fs::extension("a/") == "." );
Why this? IMO it's not clear why this should be correct.
It follows from the POSIX Pathname Resolution spec (4.11): "A pathname that contains at least one non-slash character and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname." IIRC, Windows operates the same way
This means that a leaf path has a file extension. On directory's view this is not equal to the current dir notation.
Not sure I understand your point. Could you clarify with an example?
Thanks, Olaf
BTW, what about the support on hard- and softlinks mentioned in this list some times ago?
Hard links have been supported for quite a while. Symlink creation work is stalled because of other commitments. May be ready for the next release, at least for files. For directory support on Windows, there are some really tricky issues that have bogged work down. --Beman
"A pathname that contains at least one non-slash character and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname."
IIRC, Windows operates the same way
This means that a leaf path has a file extension. On directory's view this is not equal to the current dir notation.
Not sure I understand your point. Could you clarify with an example?
A "." means the current work directory as you know. This is what I would get if I pass a path like "a/" (obviously a path) to fs::extension. Further processing inside my application would result into a wrong directory even on concatenation on paths e.g. to find some settings related to system paths. Well, I'm not sure if this would be relevant in praxis (path concatenation) since I'm not interested in path extensions by this imo, isn't it? Finally, this question is: is fs::extension suitable with paths or even only with files? Do I have to ensure this on those test. Thanks, Olaf
participants (2)
-
Beman Dawes -
Olaf Peter