Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#1331 closed defect (fixed)

wrong results from probe-file/open on many symlinks

Reported by: jared Owned by: rme
Priority: minor Milestone:
Component: other Version: trunk
Keywords: file, symlinks, probe-file, too many symlinks Cc:



This is a very minor bug, but we ran into it in the context of a much larger system and it took awhile to figure out what was going on. This is on CCL 1.11-dev-r16394M-trunk on a Linux 2.6.32-431.el6.x86_64 system.

Setup: Create a file and several levels of symlinks to it. The following will work for this in bash:

    echo "Hello World" > 0
    for ((i=0;i < 30;i=i+1)) do ln -s $i $((i+1)) ; done

Once we get past enough symlinks, we find that CCL reports that the files do not exist:

   > (probe-file "8")
   > (probe-file "20")
   > (probe-file "21")
   NIL    ;; Bug?  Expected #P"/home/users/jared/ccl-symlinks/0"
   > (probe-file "22")
   NIL    ;; Bug?  Expected #P"/home/users/jared/ccl-symlinks/0"

We also run into problems when trying to open these files. For instance:

    (defun my-read (filename)
      (with-open-file (stream filename :direction :input)
        (read-line stream)))

    > (my-read "8")
    "Hello World"
    > (my-read "20")
    "Hello World"
    (my-read "21")  ;; Bug?  The file does exist...
    > Error: No such file or directory : "21"
    > While executing: CCL::MAKE-FILE-STREAM, in process listener(1).
    > Type :POP to abort, :R for a list of available restarts.
    > Type :? for other options.

From poking around, it seems like this may be due to the way that #_REALPATH is used in the implementation of %REALPATH, which is used by PROBE-FILE. It looks like the C realpath() function can return many kinds of error conditions, such as ELOOP, which don't necessarily mean that the file doesn't exist, but that the implementation of probe-file essentially just checks its return value without paying attention to the ERRNO.

FWIW, it seems that SBCL can PROBE-FILE all of these files without a problem, but it too fails to open files from "9" and above. Fortunately it provides a good error message instead of saying that the file does not exist:

    error opening #P"/home/users/jared/ccl-symlinks/9":
      Too many levels of symbolic links

Anyway this is all minor, but it would be nice if probe-file would either report that the file does indeed exist or give a "too many symlinks" error, and similarly it would be nice if opening the file either worked or produced a "too many symlinks" error instead of saying the file doesn't exist.



Change History (4)

comment:1 Changed 6 years ago by rme

  • Owner set to rme
  • Status changed from new to assigned

comment:2 Changed 6 years ago by rme

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [16646]) In %realpath, signal a file-error if the call to #_realpath fails with an error other than ENOENT.

Closes ticket:1331.

comment:3 Changed 6 years ago by rme

There seems to have been an issue with #_realpath in older OS X releases (pre-10.6): on these systems, the last component of the passed-in file name didn't need to exist. This, presumably, is the cause of the comment in probe-file that complains that "Darwin's #_realpath will happily return non-nil for files that don't exist." discusses the issue.

comment:4 Changed 6 years ago by jared

Looks like this is working great for me now.

Thanks for the quick fix!

Note: See TracTickets for help on using tickets.