Steel Bank Common Lisp

DELETE-FILE uses wrong current working directory

Reported by Ilya Perminov on 2011-10-28
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
High
Unassigned

Bug Description

If DELETE-FILE is called with a relative file name, it passes it to Unix unlink without expanding it to an absolute path.
Test case:
(with-open-file (s #p"/tmp/test-file" :direction :output :if-exists :supersede)
           (print 0 s))
(sb-posix:chdir "/")
(setf *default-pathname-defaults* #p"/tmp/")
(probe-file #p"test-file") ; => #P"/tmp/test-file"
(delete-file #p"test-file") ; => Error: couldn't delete test-file: No such file or directory

Anton Kovalenko (anton-sw4me) wrote :

Seems easy to fix. Here's how it was fixed in my lfn-upstream branch:
https://github.com/akovalenko/sbcl-win32-threads/commit/7991c2c2c33faced2a6bb1d00c8dc1b8a5db11ba

Changed in sbcl:
status: New → In Progress
importance: Undecided → High
Anton Kovalenko (anton-sw4me) wrote :

Note that DELETE-DIRECTORY currently has the same problem: it's a SBCL-specific extension, but I'd expect any function accepting a pathname designator to use *default-pathname-defaults* when it works with filesystem. The commit above contains a hunk for DELETE-DIRECTORY too.

Maybe it should be factored out into a macro, like (WITH-PHYSICAL-PATHNAME ...), to enforce uniform *d-p-d* handling over all present and future filesystem functions working with pathnames.

Nikodemus Siivola (nikodemus) wrote :

WITH-PHYSICAL-PATHNAME sounds like a good idea.

Changed in sbcl:
assignee: nobody → Nikodemus Siivola (nikodemus)
Ilya Perminov (iperminov) wrote :

RENAME-FILE uses TRUENAME. If DELETE-FILE and co use MERGE-PATHNAMES, RENAME-FILE will need to be changed to use MERGE-PATHNAMES too for consistency.

Nikodemus Siivola (nikodemus) wrote :

commit 2a0f8515245d080dee97b72ee910c5dcbc4fc5e4
Author: Nikodemus Siivola <email address hidden>
Date: Sun Oct 30 21:51:30 2011 +0200

    make DELETE-FILE respect *DEFAULT-PATHNAME-DEFAULTS*

      MERGE-PATHNAMES to get an absolute pathname. (Using TRUENAME would be wrong,
      since then we would delete files pointed to by symbolic links, and not the
      symbolic links themselves -- a nasty regression that would be!)

      Also remove the "for error checking" TRUENAME call from there: unlink will
      give us an errno that tells what we need to know -- and lo! there is one
      race condition less in the system.

      Previously using relative pathnames it was possible to accidentally delete
      the wrong file.

      Fixes lp#882877.

      NB: currently DELETE-DIRECTORY and RENAME-FILE use TRUENAME with just the
          aforementioned unfortunate consequence, but I'm hesitant to change them
          during the freeze -- so dealing with this issue in them will have to
          wait a bit.

Changed in sbcl:
assignee: Nikodemus Siivola (nikodemus) → nobody
status: In Progress → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers