Bug in ntpath.exists?

[Fredrik Lundh]

Andrew Clover <esuzm at primrose.csv.warwick.ac.uk> wrote:
> There seems to be a problem in os.path.exists on WinNT, and presumably the
> other os.stat-based calls in ntpath.
> 
> It returns true (well, 1) for objects with any number of spurious '.' and '"'
> characters on the end of a filepath, and any number of spurious spaces on the
> end of the filepath after these. Additionally any path element may contain a
> single spurious '.' character at the end. (Also each path separator may
> consist of any number of forward- or back-slashes, but that's probably
> intended.)

that's an NT file system "feature".  trying to work around
it in the interface layer is probably a bad idea (when you
think you've got it 100% right, Microsoft releases yet an-
other implementation...)

> That is, if the file 'e:\fish\chips.txt' exists, the following paths are also
> claimed by exists to exist:
> 
>   'e:\fish\chips.txt.'
>   'e:\fish.\chips.txt"""'
>   'e:\fish/\/\/\chips.txt....      '

not to mention:

   'e:\FISH\CHIPS.TXT'

;-)

assuming you have an NTFS drive, you can also
try opening "e:\fish\chips.txt::$DATA"...

> This leniency could be considered a good thing in some cases, but not in my
> case since I'm writing a 404 CGI script which attempts to verify the missing
> URL searched for and corrent wrong parts.

to be on the really safe side, your script should
probably use something like:

    fragment in os.listdir(prefix)

to make sure there's really something called fragment
with the given prefix.  (better ideas are welcome...)

</F>