Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-1034337 ] recursive file/dir delete broken on OSX
|
From: SourceForge.net <no...@so...> - 2005-09-30 05:59:34
|
Bugs item #1034337, was opened at 2004-09-24 14:18 Message generated for change (Settings changed) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1034337&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 36. File System >Group: current: 8.4.11 >Status: Open Resolution: Fixed >Priority: 8 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Jeffrey Hobbs (hobbs) Summary: recursive file/dir delete broken on OSX Initial Comment: Submitted by: Sue LoVerso, su...@sl... Recursive, forced delete of a directory fails on OSX. TraverseUnixTree should be fixed in tclUnixFCmd.c (or a macosx-specific version written). Apple has this to say: http://docs.info.apple.com/article.html?artnum=107884 There may be other places using that same construct for readdir, I didn't look for them. TraverseUnixTree is the one affecting me. This simple script illustrates the problem: proc x { } { set nfiles 250 puts "Creating $nfiles files" file delete -force ./TESTDIR file mkdir ./TESTDIR for { set i 0 } { $i < $nfiles } { incr i } { file copy ./x.tcl ./TESTDIR/x.tcl.$i } puts "Deleting $nfiles in TESTDIR" set stat [catch {file delete -force ./TESTDIR} ret] if { $stat != 0 } { puts "Error: stat $stat, ret $ret" set filelist [exec ls ./TESTDIR] puts "FILES: $filelist" } else { puts "Delete successful" } } Multiple calls to 'file delete -force ./TESTDIR' will eventually work. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-09-29 11:04 Message: Logged In: NO Issue: Side effect of this bug fix: Removing a file/dir using command "file delete -force" command hangs in Tcl 8.4.9, if the directory in question contains a temporary NFS file .nfsXXXX. unix> lr total 2 drwxr-xr-x 18 arvin eng7 1024 Sep 23 11:50 .. -rw-r--r-- 1 arvin eng7 0 Sep 23 11:50 .nfsB93A drwxr-xr-x 2 arvin eng7 96 Sep 23 11:51 . A NFS temp file is created and conents have been copied to this file. unix> tclsh % info patchlevel 8.4.6 % file delete -force tail-f_issue error deleting "tail-f_issue": file already exists % exit unix> tclsh % info patchlevel 8.4.9 % file delete -force tail-f_issue <hangs>....... This file cannot be deleted. If deleted, it gets re-created by NFS with a different number. Trussing the tcl process revealed that Tcl spins it's cycles in futile attempt to delete this file. truss -fae -p 5589 <snip> 5589: lstat64("tail-f_issue/.nfs95701", 0xFFBEDD30) = 0 5589: unlink("tail-f_issue/.nfs95701") = 0 5589: getdents64(3, 0x0004F038, 1048) = 0 5589: llseek(3, 0, SEEK_CUR) = 96 5589: llseek(3, 0, SEEK_SET) = 0 5589: getdents64(3, 0x0004F038, 1048) = 80 5589: lstat64("tail-f_issue/.nfsA5701", 0xFFBEDD30) = 0 5589: unlink("tail-f_issue/.nfsA5701") = 0 5589: getdents64(3, 0x0004F038, 1048) = 0 5589: llseek(3, 0, SEEK_CUR) = 96 5589: llseek(3, 0, SEEK_SET) = 0 5589: getdents64(3, 0x0004F038, 1048) = 80 5589: lstat64("tail-f_issue/.nfsB5701", 0xFFBEDD30) = 0 5589: unlink("tail-f_issue/.nfsB5701") = 0 5589: getdents64(3, 0x0004F038, 1048) = 0 5589: llseek(3, 0, SEEK_CUR) = 96 5589: llseek(3, 0, SEEK_SET) = 0 5589: getdents64(3, 0x0004F038, 1048) = 80 5589: lstat64("tail-f_issue/.nfsC5701", 0xFFBEDD30) = 0 5589: unlink("tail-f_issue/.nfsC5701") = 0 5589: getdents64(3, 0x0004F038, 1048) = 0 5589: llseek(3, 0, SEEK_CUR) = 96 5589: llseek(3, 0, SEEK_SET) = 0 5589: getdents64(3, 0x0004F038, 1048) = 80 5589: lstat64("tail-f_issue/.nfsD5701", 0xFFBEDD30) = 0 <snip> ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-09-29 11:02 Message: Logged In: NO Issue: Side effect of this bug fix: Removing a file/dir using command "file delete -force" command hangs in Tcl 8.4.9, if the directory in question contains a temporary NFS file .nfsXXXX. unix> lr total 2 drwxr-xr-x 18 arvin eng7 1024 Sep 23 11:50 .. -rw-r--r-- 1 arvin eng7 0 Sep 23 11:50 .nfsB93A drwxr-xr-x 2 arvin eng7 96 Sep 23 11:51 . A NFS temp file is created and conents have been copied to this file. unix> tclsh % info patchlevel 8.4.6 % file delete -force tail-f_issue error deleting "tail-f_issue": file already exists % exit unix> tclsh % info patchlevel 8.4.9 % file delete -force tail-f_issue <hangs>....... This file cannot be deleted. If deleted, it gets re-created by NFS with a different number. Trussing the tcl process revealed that Tcl spins it's cycles in futile attempt to delete this file. truss -fae -p 5589 <snip> 5589: lstat64("tail-f_issue/.nfs95701", 0xFFBEDD30) = 0 5589: unlink("tail-f_issue/.nfs95701") = 0 5589: getdents64(3, 0x0004F038, 1048) = 0 5589: llseek(3, 0, SEEK_CUR) = 96 5589: llseek(3, 0, SEEK_SET) = 0 5589: getdents64(3, 0x0004F038, 1048) = 80 5589: lstat64("tail-f_issue/.nfsA5701", 0xFFBEDD30) = 0 5589: unlink("tail-f_issue/.nfsA5701") = 0 5589: getdents64(3, 0x0004F038, 1048) = 0 5589: llseek(3, 0, SEEK_CUR) = 96 5589: llseek(3, 0, SEEK_SET) = 0 5589: getdents64(3, 0x0004F038, 1048) = 80 5589: lstat64("tail-f_issue/.nfsB5701", 0xFFBEDD30) = 0 5589: unlink("tail-f_issue/.nfsB5701") = 0 5589: getdents64(3, 0x0004F038, 1048) = 0 5589: llseek(3, 0, SEEK_CUR) = 96 5589: llseek(3, 0, SEEK_SET) = 0 5589: getdents64(3, 0x0004F038, 1048) = 80 5589: lstat64("tail-f_issue/.nfsC5701", 0xFFBEDD30) = 0 5589: unlink("tail-f_issue/.nfsC5701") = 0 5589: getdents64(3, 0x0004F038, 1048) = 0 5589: llseek(3, 0, SEEK_CUR) = 96 5589: llseek(3, 0, SEEK_SET) = 0 5589: getdents64(3, 0x0004F038, 1048) = 80 5589: lstat64("tail-f_issue/.nfsD5701", 0xFFBEDD30) = 0 <snip> ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2004-11-10 17:26 Message: Logged In: YES user_id=90580 fix committed to HEAD and core-8-4-branch and attached. also added a testcase for this bug. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-09-27 05:27 Message: Logged In: YES user_id=32170 Daniel is probably best placed to suggest the appropriate fix (or take that from the apple.com webpage cited). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1034337&group_id=10894 |