[pg-cvs] Bug in delete-directory-and-files
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 -- http://www.linkedin.com/in/polzer
"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? -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
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 -- http://www.linkedin.com/in/polzer
"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? -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
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. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
On Sun, Aug 16, 2009 at 6:11 PM, Luis Oliveira<luismbo@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
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 -- http://www.linkedin.com/in/polzer
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 -- http://www.linkedin.com/in/polzer
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 -- http://www.linkedin.com/in/polzer
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 -- http://www.linkedin.com/in/polzer
"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. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
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
participants (4)
-
John Fremlin -
Julian Squires -
Leslie P. Polzer -
Luis Oliveira