argh. smash. Win32.

[Alexei Kosut <ak...@leland.Stanford.EDU>]

This is getting me more and more frustrated.

Apparently, Marc, I was wrong about what the Win32 functions seem to do.
I don't know why, precisely, but it appears now that GetFullPathName does
in fact, not only strip trailing spaces and things, but trailing dots as
well. The odd thing is that I don't seem to recall it doing that. It's
possible I just missed it. Except that the ... problem seemed real enough,
IIRC. GetFullPathName() definitely appears to translate "/.../" into
"/../" and "/..." into "/". And it appears to get eliminated, as per the
latter. So I'm not sure why this was showing up as a problem. Can anyone
recap?

And FindFirstFile now does appear to be doing some canonicalization. It
does weird things like removing < from filenames. But not >, or | or
anything else. Just <. Hmm. It may also remove spaces and dots, although
the GetFullPathName() call gets to it first.

And there's one really evil problem inherent in what I want to do: < > | "
: will never exist in a filename. I want to reject access to files with
those names. But unfortunately, we do want to allow them in PATH_INFO
(especially :). But, of course, the PATH_INFO of a directory is the
filename that doesn't exist. i.e., there's no easy way AFAIK to reject
these filenames without rejecting legal PATH_INFO. I don't think it can be
done easily from within os_canonical_filename(), it may have to get deeper
into directory_walk, after the PATH_INFO has been stripped off.

I need to sleep on this before I can puzzle anything out.

P.S. Ben, the current os_canonical_filename does mess up PATH_INFO - the
GetFullPathName() call, which we always figured did nothing for a
non-existant filename, actually removes any trailing spaces or dots (I
think) from each path segment. Including PATH_INFO.

-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *