Re: [Chicken-hackers] [PATCH] handle EOVERFLOW and ENOTDIR gracefully in file/directory-exists?

[Peter Bex]

On Sat, Oct 08, 2011 at 04:30:12PM -0400, John Cowan wrote:
> Here's my argument:  file-exists? should return #t if the file definitely
> exists and #f if it definitely doesn't, and should throw an exception
> if the implementation cannot tell.  In the case of ENAMETOOLONG, the
> file *cannot* exist, so returning #f (and not throwing an exception)
> is the Right Thing.

This is not true in Windows.  Apparently there's a limit of 260 characters
in the full pathname (including drive letter), but if you use "subst" to map
a directory to a different directory, the limit resets.  So you can actually
create directories on a drive at a deeper level than you can access!
See http://www.mail-archive.com/address@hidden/msg00360.html
This also talks about some weirdass "//?"-prefix you can use to extend the
pathname limit to 32,767 characters.  These prefixes only appear to be
supported by *some* of the system calls.  God, how broken can a system be?

Perhaps this same effect can occur in Unix where you can mount directories
under arbitrary levels in the hierarchy, even higher ones, effectively
creating paths that are too long when accessed from one mountpoint but not
from another.  And there's of course also the matter of symlinks/hardlinks.

Also, my stat(2) manpage says:
     [ENAMETOOLONG]     A component of a pathname exceeded {NAME_MAX} charac-
                        ters, or an entire path name exceeded {PATH_MAX} char-
                        acters.

I don't know if I interpret this correctly, but if you pass in a large
relative pathname with lots of ../foo/../../bar/../../ stuff in it,
it might also return ENAMETOOLONG, even though if you normalise the path,
it will be shorter, so the file *could* exist.

I think just returning #f on ENAMETOOLONG is asking for trouble.
Simply punting on the issue by throwing an error is probably safer.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth