RE: [boost] Re: relative/absolute paths in filesystem library

From: Glen Knowles (gknowles_at_[hidden])
Date: 2002-11-26 22:33:29

From: Beman Dawes [mailto:bdawes_at_[hidden]]

 >>current_directory() - returns the current directory (and drive if 
 >>windows)
 >
 >That's been added, per the formal review. The actual names for it 
 >and its sibling function will be current_path() and initial_path(), 
 >to reflect the fact that a path rather than just a directory name 
 >are returned.

I'm not sure what initial_path() is, but I believe current_path() 
should be current_directory() because:

1. It is the common name for it.
2. What I want is a directory (the current one), a path might not be
a directory. I agree that current_directory_path() is better then
current_directory_name(), but the fact that its a directory is 
what's important. What would be the name for current_drive() ?

 >>is_absolute() - true if the directory (sans drive) starts with 
 >>a / (c:/, /, /blah are absolute; c:blah, blah, ../blah are not)
 >
 >That's been added too.
 >
 >Hum... On multi-rooted operating systems like Windows, "/" and 
 >"/blah" are relative to the current drive, and thus not considered 
 >absolute. AFAIR, that was mentioned several times and was not 
 >controversial. What was your rationale?

I don't know if it was controversial, but I did bring this up during 
the review and I do think its very important. The basic definition
of an absolute path should be a path that overrides the base path
during a resolve. To rephrase, 'foo' is relative because it is an 
adjustment from the current directory, '/foo' on the other hand 
takes precendence over the current path. To re-rephrase, '/foo' is
relative to the current drive, but not to the current directory.

I deal with URLs as much as with file paths and this does color
my thinking. The way I have outlined it I am able to use windows
drives and URL authorities with exactly the same semantics. 

 >>make_absolute() - prepends current drive if no drive is defined, 
 >>inserts current directory after the drive if it is not an absolute 
 >>path
 >
 >If I understand you correctly, make_absolute() and resolve() differ 
 >in that the source of the "base" path in make_absolute() is hardwired. 
 >Because the "base" path is always absolute with make_absolute(), 
 >result is always absolute.

There is more to it then that. make_absolute() uses the authority 
(windows drive) given in the path if it is present, otherwise using
the current drive. So make_absolute(a:foo) is different from 
resolve(c:/bar, a:foo) where c:/bar is the current directory, because
make_absolute(a:foo) is a request to make it absolute with respect
to the current directory of drive A.

Referring to resolve. . . 

 >These semantics seem carefully worked out, and there are probably 
 >cases where they are exactly what is required.
 >
 >On the other hand, these semantics are complex, and may cause 
 >confusion. It is easy to incorrectly assume the result is always 
 >absolute. The preconditions and postconditions seem unclear. Are 
 >exceptions are being thrown for what are really preconditions?

There are really two basic rules. Resolving from one authority or drive
to another is illegal, and a path starting with a / is absolute with
respect to its authority.

 >Thomas Witt pointed out that with a full set of decomposition functions 
 >to grab portions of a path, it becomes easy to write code like:

<snip>

 >These semantics aren't the same as your resolve() or make_absolute(), 
 >but may be what is required for some applications.

The semantics I'm arguing for are mandated for urls (RFC 1808 to name 
one of many) and work well for file paths.

If I haven't said it before, thanks for all of your work on the
filesystem library (and boost in general), it is an important piece 
missing from the standard.

Glen