DELETE-FILE uses wrong current working directory

[Ilya Perminov]

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)]

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

[Anton Kovalenko (anton-sw4me)]

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)]

WITH-PHYSICAL-PATHNAME sounds like a good idea.

[Ilya Perminov (iperminov)]

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)]

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.