Sorry, no time to commit this myself, I'm buried. If we want Apache 2.0 beta out the door by ApacheCon, I need to give that some attention in my free moments between my work assignments. So may I pass this on for review and commitment?
[I haven't even fully parsed the way he stated things, although this is most definately the gist of it. The statement about / is definately correct. I don't know that we have a VMS port :-? But this should probably mention OS2 as well.] Bill ----- Original Message ----- From: Ted Sharpe To: [EMAIL PROTECTED] Sent: Tuesday, March 06, 2001 9:54 PM Subject: Documentation you requested on mulitple volumes. (Last night's USENET.) Dear Mr. Rowe, Thanks for your kind, and astoundingly prompt, reply to my question about the treatment of multiple-volume file systems (news:[EMAIL PROTECTED]). You invited me to attempt a write-up of the issue, and here's the best I can do given my limited understanding. I trust you'll vet it for accuracy, and simply discard it if it's too hopeless. I don't know where it goes in the docs--there doesn't seem to be a place where pathnames in general are discusses. Perhaps it could be stuck into the core.html as a footnote. Regards, Ted. A special note for operating systems with multiple-volume file systems (like VMS, Netware, or Windows): Unlike Unix, which has a single root directory that anchors the entire file hierarchy, certain operating systems support file systems in multiple volumes. Windows (like DOS before it) uses a drive letter to specify the volume--the C: drive, for example. VMS and Netware use a similar scheme with more general volume names--for example, sys: on a Netware system. The Apache configuration files on these platforms accept volume names (and, in general, file specifications that use local conventions). Windows Example: ServerRoot "C:\Program Files\Apache Group" Some configuration directives allow you to specify incomplete pathnames. (Under Unix, these are usually called "relative" paths.) The usual rule is that the missing parts of the name are supplied from some other name--frequently the ServerRoot. Under multiple-volume operating systems, this same idea is applied to missing volume designators: the volume designator will be taken to be that of the ServerRoot. Note that some of the documentation indicates that you can tell the difference between an absolute pathname and a relative pathname by checking whether or not it begins with a "/". On multiple-volume systems this isn't really true: a fully qualified pathname includes the volume designator, and therefore doesn't begin with "/". The code knows this, and pathnames are "canonicalized", that is, extended to fully qualified pathnames, appropriately for each system. The container directives that take pathnames treat each volume as the separate hierarchy that it, in fact, is. Here are some examples from Windows: <Directory "C:\"> covers every directory on the C: drive, but does not apply to any directory from any other drive. <Directory "D:\foo\"> covers the "foo" directory, and those below it on drive D:, but, even if there are top-level directories named "foo" on other drives, it doesn't apply to them. In short, it probably works like you'd guess it would--nothing surprising. There is, however, one very special exception to all of this: even on multiple-volume operating systems the container <Directory "/"> is treated as a special case that applies to absolutely everything. This is to allow you to easily specify default options that will apply to all volumes. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
