In the 1.0.29.x series, DELETE-FILE started deleting the truename of the
given pathname designator (rather than the pathname itself), meaning
that symlinks could no longer be deleted. Revert back to the historical
behaviour. (Noted on sbcl-devel by Luis Oliveira 2009-08-18.)
Although the behaviour hasn't changed recently, there's a similar issue
in RENAME-FILE, but that operator has such bizarre behaviour anyway it
might be worth just letting sleeping pathname functions lie.
* bug fix: DELETE-FILE on streams no longer closes the stream with :ABORT T,
leading to possible attempts to delete the same file twice. See docstring
on DELETE-FILE for details. (reported by John Fremlin)
+ * bug fix: DELETE-FILE once again deletes the file named by the pathname
+ designator argument, rather than its truename. (reported by Luis
+ Oliveira)
* bug fix: the low-level debugger had 32-bit assumptions and was missing
information about some array types. (thanks to Luis Oliveira)
* bug fix: moderately complex combinations of inline expansions could
plaforms the stream remains open, allowing IO to continue: the OS resources
associated with the deleted file remain available till the stream is closed as
per standard Unix unlink() behaviour."
- (let* ((truename (truename file))
- (namestring (native-namestring truename :as-file t)))
+ (let* ((pathname (pathname file))
+ (namestring (native-namestring pathname :as-file t)))
+ (truename file) ; for error-checking side-effect
#!+win32
(when (streamp file)
(close file))
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"1.0.30.48"
+"1.0.30.49"