| Ticket UUID: | 1035775 | |||
| Title: | filesystem-7.6 and 7.7 fail | |||
| Type: | Bug | Version: | obsolete: 8.5a2 | |
| Submitter: | kennykb | Created on: | 2004-09-27 22:12:46 | |
| Subsystem: | 37. File System | Assigned To: | dgp | |
| Priority: | 9 Immediate | Severity: | ||
| Status: | Closed | Last Modified: | 2004-11-17 07:31:57 | |
| Resolution: | Fixed | Closed By: | dgp | |
| Closed on: | 2004-11-17 00:31:57 | |||
| Description: |
On Red Hat Enterprise 3, runnning with the HEAD as of
2004-09-27 2300 UTC, I get the following two test
failures:
==== filesystem-7.6 cross-filesystem dir copy with
-force FAILED
==== Contents of test case:
set dir [pwd]
cd [tcltest::temporaryDirectory]
file delete -force simpledir
file mkdir simpledir
file mkdir dir2
set fout [open [file join simpledir simplefile] w]
puts -nonewline $fout "1234567890"
close $fout
testsimplefilesystem 1
# First copy should succeed
set res [catch {file copy simplefs:/simpledir dir2}
err]
lappend res $err
# Second copy should fail (no -force)
lappend res [catch {file copy simplefs:/simpledir
dir2} err]
lappend res $err
# Third copy should succeed (-force)
lappend res [catch {file copy -force
simplefs:/simpledir dir2} err]
lappend res $err
lappend res [file exists [file join dir2
simpledir]] [file exists [file join dir2 simpledir
simplefile]]
testsimplefilesystem 0
file delete -force simpledir
file delete -force dir2
cd $dir
set res
---- Result was:
1 {error copying "simplefs:/simpledir": no such file or
directory} 1 {error copying "simplefs:/simpledir": no
such file or directory} 1 {error copying
"simplefs:/simpledir": no such file or directory} 0 0
---- Result should have been (exact matching):
0 {} 1 {error copying "simplefs:/simpledir" to
"dir2/simpledir": file already exists} 0 {} 1 1
==== filesystem-7.6 FAILED
==== filesystem-7.7 cross-filesystem dir copy with
-force FAILED
==== Contents of test case:
set dir [pwd]
cd [tcltest::temporaryDirectory]
file delete -force simpledir
file mkdir simpledir
file mkdir dir2
set fout [open [file join simpledir simplefile] w]
puts -nonewline $fout "1234567890"
close $fout
testsimplefilesystem 1
# First copy should succeed
set res [catch {file copy simplefs:/simpledir dir2}
err]
lappend res $err
# Second copy should fail (no -force)
lappend res [catch {file copy simplefs:/simpledir
dir2} err]
lappend res $err
# Third copy should succeed (-force)
# I've noticed on some Unices that this only succeeds
# intermittently (some runs work, some fail). This
needs
# examining further.
lappend res [catch {file copy -force
simplefs:/simpledir dir2} err]
lappend res $err
lappend res [file exists [file join dir2
simpledir]] [file exists [file join dir2 simpledir
simplefile]]
testsimplefilesystem 0
file delete -force simpledir
file delete -force dir2
cd $dir
set res
---- Result was:
1 {error copying "simplefs:/simpledir": no such file or
directory} 1 {error copying "simplefs:/simpledir": no
such file or directory} 1 {error copying
"simplefs:/simpledir": no such file or directory} 0 0
---- Result should have been (exact matching):
0 {} 1 {error copying "simplefs:/simpledir" to
"dir2/simpledir": file already exists} 0 {} 1 1
==== filesystem-7.7 FAILED
| |||
| User Comments: |
dgp added on 2004-11-17 07:14:08:
File Added - 109039: 1035775.patch Logged In: YES user_id=80530 here's a patch supplying a simpleminded fix that I am committing. dgp added on 2004-11-17 06:52:58: Logged In: YES user_id=80530 I think I found it. The resetting of tsdPtr->filesystemEpoch gets done within TclFSEpochOK while the intrep of the "dir2" path is getting rechecked. Later when FsGetFirstFilesystem() is called, the epochs match, so the call to FsRecacheFilesystemList() is skipped, even though it is needed in order to be able to find the "simple" Tcl_Filesystem. dgp added on 2004-11-17 06:35:27: Logged In: YES user_id=80530 In filesystem-7.6, during the [file copy simplefs:/simpledir dir2] command, a call to Tcl_FSGetFileSystemForPath() is returning "native" instead of the correct "simple" for the path simple:/simpledir dgp added on 2004-11-17 05:49:24: Logged In: YES user_id=80530 still tracking this down. Now appears that intervening [testsimplefilesystem] may matter more than the intervening [cd]. vincentdarley added on 2004-11-17 05:22:57: Logged In: YES user_id=32170 Zoran, Any ideas from a threading perspectve? dgp added on 2004-11-17 03:32:34: Logged In: YES user_id=80530 It appears the problem is that the relative path "dir2" gets an internal rep before a [cd], then uses it after the [cd], even though it is then out of date. something about the cwd up to date check is failing when threads are enabled. dgp added on 2004-11-17 03:02:25: Logged In: YES user_id=80530 the portion of that change set that is most obviously influenced by --enable-threads is the TclFSEpochOk() routine. Suspect that's the best place to look for root causes. dgp added on 2004-11-17 02:56:25: Logged In: YES user_id=80530 confirmed that the following change started the failures: 2004-09-27 Vince Darley <[email protected]> * generic/tclFileName.c: * generic/tclFileSystem.h: * generic/tclIOUtil.c: * generic/tclPathObj.c: * tests/cmdAH.test: * tests/fileSystem.test: * tests/winFCmd.test: fix to bad error message with 'cd' on windows, when permissions are inadequate [Bug 1035462] and to treatment of a volume-relative pwd on Windows [Bug 1018980]. * doc/FileSystem.3: added missing Tcl_GlobTypeData documentation [Bug 935853] dgp added on 2004-11-17 02:27:57: Logged In: YES user_id=80530 I confirm that works around the failures, but the fact remains these failures happen only under a --enable-threads configuration, while nothing in fileSystem.test appears to be contingent on thread-enabling. To me, this says there's a bug to be found in the thread-enabled configuration. We ought to find and fix it rather than hide it. das added on 2004-11-11 08:05:32: Logged In: YES
user_id=90580
also ran into this the other day and fiddled around a bit, it turns out that
these tests only fail when executed as part of filesystem.test and not
when run as independent snippets.
the problem seems to be with reuse of directory names (some PathObj
issue?), as when the 'dir2' in these tests is changed to 'dir3', they pass.
I also managed to workaround the failure with the change below, which
again only changes a 'dir2' pathname earlier on in the testfile to './dir2'...
haven't tried to investigate any further, HTH a bit...
Index: tests/fileSystem.test
===============================================
====================
RCS file: /cvsroot/tcl/tcl/tests/fileSystem.test,v
retrieving revision 1.49
diff -u -p -r1.49 fileSystem.test
--- tests/fileSystem.test31 Oct 2004 17:36:41 -00001.49
+++ tests/fileSystem.test10 Nov 2004 17:02:39 -0000
@@ -261,7 +261,7 @@ test filesystem-1.29.1 {link normalisati
file delete -force dir2.file
file delete -force dir2.link
file delete -force link.file dir.link
-file delete -force dir2
+file delete -force ./dir2
file delete -force [file join dir.dir dirinside.link]
removeFile [file join dir.dir inside.file]
removeDirectory [file join dir.dir dirinside.dir]
dgp added on 2004-10-27 23:53:25: Logged In: YES user_id=80530 this needs fixing before an 8.5a2 release. andreas_kupries added on 2004-10-07 04:08:28: Logged In: YES user_id=75003 I can confirm this for a linux and a windows build. Windows is Win 2K. dgp added on 2004-10-05 22:34:44: Logged In: YES user_id=80530 these tests fail on thread-enabled Solaris builds also. there must be some real thread related bug. dgp added on 2004-09-30 11:08:13: Logged In: YES user_id=80530 these tests just recently started failing on the HEAD on thread-enabled macosx builds. vincentdarley added on 2004-09-28 15:47:05: Logged In: YES user_id=32170 Did these break as a result of my check-in yesterday, or have they been broken for a long time? | |||
Attachments:
- 1035775.patch [download] added by dgp on 2004-11-17 07:14:08. [details]