Observe:
% ls -Rl /tmp/foo /tmp/foo: -rw-r--r-- 1 sky users 4625 1997-11-14 21:04 symlinks_1.2.orig.tar.gz
/tmp/foo/src: symlinks_1.2.orig.tar.gz -> /tmp/foo/symlinks_1.2.orig.tar.gz
Now when I call delete-directory-and-files on it I get:
debugger invoked on a OSICAT-POSIX:ENOTEMPTY in thread #<THREAD "initial thread" RUNNING {A9058A1}>: #<ENOTEMPTY 39 :ENOTEMPTY "">
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(OSICAT-POSIX:POSIX-ERROR 39 NIL) 0] :ba
0: (OSICAT-POSIX:POSIX-ERROR 39 NIL) 1: (OSICAT-POSIX::SYSCALL-SIGNAL-POSIX-ERROR #<unavailable argument> NIL) 2: (OSICAT:DELETE-DIRECTORY #P"src/") 3: ((LAMBDA (#:ONE-ITER336)) #<CLOSURE (LABELS OSICAT::ONE-ITER) {AA12545}>) 4: (OSICAT::CALL-WITH-DIRECTORY-ITERATOR #P"/tmp/foo/" #<CLOSURE (LAMBDA #) {AA121ED}>) 5: ((LABELS OSICAT::WALK) #P"/tmp/foo/") 6: (OSICAT:WALK-DIRECTORY #P"/tmp/foo/" #<FUNCTION (LAMBDA #) {B815CF5}>)[:EXTERNAL] 7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (OSICAT:DELETE-DIRECTORY-AND-FILES #P"/tmp/foo/") #<NULL-LEXENV>) 8: (INTERACTIVE-EVAL (OSICAT:DELETE-DIRECTORY-AND-FILES #P"/tmp/foo/"))[:EXTERNAL] 9: (SB-ACLREPL::REP-ONE) 10: (SB-ACLREPL::REPL)[:EXTERNAL] 11: ((LAMBDA (SB-ACLREPL::NOPRINT)) NIL) 12: ((LAMBDA ())) 13: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {A98F005}>) 14: (SB-IMPL::TOPLEVEL-REPL NIL) 15: (SB-IMPL::TOPLEVEL-INIT) 16: ((LABELS SB-IMPL::RESTART-LISP))
A second call finishes without error.
I'm not sure what's the cause for this, but I think something about the filename is fishy.
Leslie
"Leslie P. Polzer" sky@viridian-project.de writes:
% ls -Rl /tmp/foo /tmp/foo: -rw-r--r-- 1 sky users 4625 1997-11-14 21:04 symlinks_1.2.orig.tar.gz
/tmp/foo/src: symlinks_1.2.orig.tar.gz -> /tmp/foo/symlinks_1.2.orig.tar.gz
Now when I call delete-directory-and-files on it I get:
debugger invoked on a OSICAT-POSIX:ENOTEMPTY in thread #<THREAD "initial thread" RUNNING {A9058A1}>: #<ENOTEMPTY 39 :ENOTEMPTY "">
Sorry, I can't reproduce this.
$ ls -Rl /tmp/foo /tmp/foo: total 4 drwxr-xr-x 2 luis luis 4096 2009-08-16 22:53 src -rw-r--r-- 1 luis luis 0 2009-08-16 22:52 symlinks_1.2.orig.tar.gz
/tmp/foo/src: total 0 lrwxrwxrwx 1 luis luis 33 2009-08-16 22:53 symlinks_1.2.orig.tar.gz -> /tmp/foo/symlinks_1.2.orig.tar.gz
$ sbcl [...] * (osicat:delete-directory-and-files #p"/tmp/foo/")
T
[...] $ ls /tmp/foo ls: cannot access /tmp/foo: No such file or directory
Am I missing some step?
Luis Oliveira wrote:
Sorry, I can't reproduce this.
Weird. Here's the whole thing from scratch:
% ls /tmp keyring-MSmdLA orbit-gdm orbit-sky ssh-JKVALh3920 % mkdir /tmp/foo/src -p % cd /tmp/foo % touch symlinks_1.2.orig.tar.gz % cd src % ln -s /tmp/foo/symlinks_1.2.orig.tar.gz % ls -l total 0 lrwxrwxrwx 1 sky users 33 2009-08-17 09:51 symlinks_1.2.orig.tar.gz -> /tmp/foo/symlinks_1.2.orig.tar.gz % sbcl (running SBCL from: /home/sky/sbcl.git.dev) This is SBCL 1.0.30.26, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. CL-USER(1): (asdf:oos 'asdf:load-op 'osicat)
; loading system definition from ; /home/sky/projects/lisp/clbuild.paktahn/systems/osicat.asd into ; #<PACKAGE "ASDF0"> ; loading system definition from ; /home/sky/projects/lisp/clbuild.paktahn/systems/trivial-features.asd into ; #<PACKAGE "ASDF1"> ; registering #<SYSTEM TRIVIAL-FEATURES {AAA6C39}> as TRIVIAL-FEATURES ; loading system definition from ; /home/sky/projects/lisp/clbuild.paktahn/systems/cffi-grovel.asd into ; #<PACKAGE "ASDF1"> ; registering #<SYSTEM CFFI-GROVEL {ACD8D69}> as CFFI-GROVEL ; loading system definition from ; /home/sky/projects/lisp/clbuild.paktahn/systems/alexandria.asd into ; #<PACKAGE "ASDF1"> ; registering #<SYSTEM :ALEXANDRIA {AE96181}> as ALEXANDRIA ; loading system definition from ; /home/sky/projects/lisp/clbuild.paktahn/systems/cffi.asd into ; #<PACKAGE "ASDF1"> ; registering #<SYSTEM CFFI {B037E69}> as CFFI
CL-USER(2): (osicat:delete-directory-and-files #p"/tmp/foo/")
debugger invoked on a OSICAT-POSIX:ENOTEMPTY in thread #<THREAD "initial thread" RUNNING {A905951}>: #<ENOTEMPTY 39 :ENOTEMPTY "">
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(OSICAT-POSIX:POSIX-ERROR 39 NIL) 0]
Specs:
Linux 2.6.30 glibc 2.10.1
Osicat: commit 725fd246adb79a87f4ac48309012e298654a1e15 Author: Stelian Ionescu sionescu@cddr.org Date: Mon Aug 10 20:14:13 2009 +0200
Change soname of wrapper library to "libosicat".
Leslie
"Leslie P. Polzer" sky@viridian-project.de writes:
This is SBCL 1.0.30.26, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/.
My guess is it has something to do with the SBCL version, as ISTR reading about some recent pathname regressions. I'm using 1.0.22.18. Can you use git-bisect to find the offending SBCL version?
Luis Oliveira luismbo@gmail.com writes:
"Leslie P. Polzer" sky@viridian-project.de writes:
This is SBCL 1.0.30.26, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/.
My guess is it has something to do with the SBCL version, as ISTR reading about some recent pathname regressions. I'm using 1.0.22.18. Can you use git-bisect to find the offending SBCL version?
OTOH, I just compiled SBCL 1.0.30.46 and failed to reproduce the bug there as well.
On Sun, Aug 16, 2009 at 6:11 PM, Luis Oliveiraluismbo@gmail.com wrote:
"Leslie P. Polzer" sky@viridian-project.de writes:
debugger invoked on a OSICAT-POSIX:ENOTEMPTY in thread #<THREAD "initial thread" RUNNING {A9058A1}>: #<ENOTEMPTY 39 :ENOTEMPTY "">
Sorry, I can't reproduce this.
Is the bug only reproducable when the working directory is inside the directory to be deleted? I can't reproduce the original bug as stated, either, but when I delete-directory-and-files from a subdirectory of the desired deletion point, I get the unsurprising error:
* (osicat:delete-directory-and-files #p"/tmp/foo/")
debugger invoked on a OSICAT-POSIX:ENOENT in thread #<THREAD "initial thread" RUNNING {AA405E1}>: #<ENOENT 2 :ENOENT "No such file or directory">
Julian Squires wrote:
Is the bug only reproducable when the working directory is inside the directory to be deleted? I can't reproduce the original bug as stated, either, but when I delete-directory-and-files from a subdirectory of the desired deletion point, I get the unsurprising error:
No, I just checked (an attempt to delete pkgdir below is made):
cwd: #P"/home/sky/.paktahn/aur/" pkgdir #P"/home/sky/.paktahn/aur/symlinks/"
==> #<ENOTEMPTY 39 :ENOTEMPTY "">
Plus it's not ENOENT but ENOTEMPTY...
I've noticed that cl-fad shows the same behavior. Perhaps something has changed in recent glibc or Linux versions?
Leslie
Some more output:
pkgdir #P"/home/sky/.paktahn/aur/symlinks/" 0: (OSICAT:DELETE-DIRECTORY-AND-FILES #P"/home/sky/.paktahn/aur/symlinks/") 1: (OSICAT:WALK-DIRECTORY #P"/home/sky/.paktahn/aur/symlinks/" #<FUNCTION (LAMBDA #) {C87A815}> :DIRECTORIES T :IF-DOES-NOT-EXIST :ERROR) file: #P"PKGBUILD" file: #P"symlinks_1.2.orig.tar.gz" file: #P"src/" 2: (OSICAT:DELETE-DIRECTORY #P"src/")
debugger invoked on a OSICAT-POSIX:ENOTEMPTY in thread #<THREAD "initial thread" RUNNING {A905A39}>: #<ENOTEMPTY 39 :ENOTEMPTY "">
Why is DELETE-DIRECTORY being called instantly on src/ although it still contains a symlink?
Leslie
Leslie P. Polzer wrote:
file: #P"PKGBUILD" file: #P"symlinks_1.2.orig.tar.gz" file: #P"src/" 2: (OSICAT:DELETE-DIRECTORY #P"src/")
debugger invoked on a OSICAT-POSIX:ENOTEMPTY in thread #<THREAD "initial thread" RUNNING {A905A39}>: #<ENOTEMPTY 39 :ENOTEMPTY "">
Why is DELETE-DIRECTORY being called instantly on src/ although it still contains a symlink?
Correction: since we're walking depth-first the second "file:" line refers to the symlink being deleted.
However my SBCL here doesn't delete the link but the target instead.
Will research this further...
Leslie
Okay, got it.
SBCL's DELETE-FILE deletes the target of a link, not the link itself.
What do you think should be done about this?
Leslie
"Leslie P. Polzer" sky@viridian-project.de writes:
SBCL's DELETE-FILE deletes the target of a link, not the link itself.
According to git-bisect, this bug was introduced by 1.0.28.59 which changed DELETE-FILE to use PROBE-FILE, which follows symlinks.
I've CCed the sbcl-devel list.
Luis Oliveira luismbo@gmail.com writes:
"Leslie P. Polzer" sky@viridian-project.de writes:
SBCL's DELETE-FILE deletes the target of a link, not the link itself.
According to git-bisect, this bug was introduced by 1.0.28.59 which changed DELETE-FILE to use PROBE-FILE, which follows symlinks.
Maybe it has something to do with this bug fix
"delete-file on stream deletes the file twice and raises error" https://bugs.launchpad.net/sbcl/+bug/406271
-
John Fremlin -
Julian Squires -
Leslie P. Polzer -
Luis Oliveira