Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-3545366 ] Win32 link normalization test failures
|
From: SourceForge.net <no...@so...> - 2012-07-27 09:07:50
|
Bugs item #3545366, was opened at 2012-07-18 04:54 Message generated for change (Comment added) made by twylite You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3545366&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: 37. File System Group: development: 8.6b3 >Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Twylite (twylite) Assigned to: Don Porter (dgp) Summary: Win32 link normalization test failures Initial Comment: Hi, Link normalization tests fail on WIN32 in a trunk build from 2012/07/18 using MSVC10, 32-bit tclsh running on Windows 7 64-bit. Details: Build setup (32-bit): 'Setting environment for using Microsoft Visual Studio 2010 x86 tools' Testing platform: Windows 7 (64-bit), PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 30 Stepping 5, GenuineIntel C:\User\Tcl_BUILD\cmake-2012\tcl-trunk>fossil pull Server: http://core.tcl.tk/tcl C:\User\Tcl_BUILD\cmake-2012\tcl-trunk>fossil update updated-to: f0f8f508748b68a589768e9e7df3beea28279df9 2012-07-17 13:08:18 UTC tags: trunk Build commands: set BUILDENV=VC10 set VER=86b3 set INSTALLDIR=%CD%\Release_%VER%_%BUILDENV% set OPTS=threads set TCLSH=%INSTALLDIR%\bin\tclsh86t.exe mkdir %INSTALLDIR% pushd win nmake /f makefile.vc release tcltest OPTS=%OPTS% CFG_ENCODING=\\\"utf-8\\\" INSTALLDIR=%INSTALLDIR% nmake /f makefile.vc install OPTS=%OPTS% CFG_ENCODING=\\\"utf-8\\\" INSTALLDIR=%INSTALLDIR% nmake /f makefile.vc test ==== filesystem-1.3 link normalisation FAILED ==== Contents of test case: testPathEqual [file normalize [file join dir.dir foo]] [file normalize [fil e join dir.link foo]] ---- Result was: not equal: C:/User/Tcl_BUILD/cmake-2012/tcl-trunk/win/dir.dir/foo C:/User/Tcl_BU ILD/cmake-2012/tcl-trunk/win/dir.link/foo ---- Result should have been (exact matching): ok ==== filesystem-1.3 FAILED ==== filesystem-1.4 link normalisation FAILED ==== Contents of test case: testPathEqual [file normalize [file join dir.dir inside.file]] [file normal ize [file join dir.link inside.file]] ---- Result was: not equal: C:/User/Tcl_BUILD/cmake-2012/tcl-trunk/win/dir.dir/inside.file C:/Use r/Tcl_BUILD/cmake-2012/tcl-trunk/win/dir.link/inside.file ---- Result should have been (exact matching): ok ==== filesystem-1.4 FAILED ==== filesystem-1.39 file normalisation with volume relative FAILED ==== Contents of test case: set drv C:/ cd [lindex [glob -type d -dir $drv *] 0] file norm [string range $drv 0 1] ---- Result was: C:/AMD ---- Result should have been (glob matching): *[^/] ==== filesystem-1.39 FAILED ---------------------------------------------------------------------- >Comment By: Twylite (twylite) Date: 2012-07-27 02:07 Message: Fix tested and confirmed. Remaining failures filesystem-1.3 and filesystem-1.4 will be handled in #3075027. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-07-19 08:15 Message: >Is the result of [file norm c:] meant to be the working directory? On Windows, each drive has its own working directory, Tcl only has a single global working directory. Therefore the behavior is not 100% what people would expect, but it's the current behavior of tclsh. Compare with: ======================= C:\>cd c:\AMD c:\AMD>dir c: Directory of c:\AMD 19-07-2012 17:07 <DIR> . 19-07-2012 17:07 <DIR> .. 0 File(s) 0 bytes 2 Dir(s) 445.538.279.424 bytes free c:\AMD>cd t:\scratch c:\AMD>dir c: Directory of c:\AMD 19-07-2012 17:07 <DIR> . 19-07-2012 17:07 <DIR> .. 0 File(s) 0 bytes 2 Dir(s) 445.538.197.504 bytes free c:\AMD>dir t: Directory of t:\scratch 19-07-2012 17:07 <DIR> . 19-07-2012 17:07 <DIR> .. 0 File(s) 12.288 bytes 2 Dir(s) 714.899.456 bytes free c:\AMD> ---------------------------------------------------------------------- Comment By: Twylite (twylite) Date: 2012-07-19 07:00 Message: Is the result of [file norm c:] meant to be the working directory? The behaviour I get is as follows: - cd c:/AMD - file norm c: --> C:/AMD - cd t:/scratch - file norm c: --> C:/ - file norm t: --> T:/scratch Is this correct? ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-07-19 06:38 Message: Now I know why I sometimes see it, sometimes not. 8.6 had the filesystem-1.39 failure, 8.5 didn't have it. Anyway, fixed it in trunk now, and tested it on Windows 7. >This test always fails, right?? Yes, it did in 8.6, but not any more. The remaining 2 failures are dup of #3075027 Great! Jan Nijtmans ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-07-19 06:10 Message: It looks like test filesystem-1.39 is just broken. The test is using glob matching, but the [^...] syntax is regexp. [string match] doesn't do that. This test always fails, right?? ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-07-19 05:59 Message: Just ran filesystem.test in current core-8-5-12-rc, but I cannot reproduce the filesystem-1.39 failure any more. I've seen it in the past. Maybe the earlier failing fCmd.test left something behind that caused this. However I suggest to close this as dup of #3075027. (8.4, 8.5 and trunk all have this) ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2012-07-19 05:41 Message: filesystem-1.[34] is failing since [40f723e2c0], since 2008-07-21. Dup of Bug #3075027 For filesystem-1.39, I don't know, but I suspect it happens only on WoW64. In other words: not critical at all for 8.5.12 IMHO ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-07-19 05:19 Message: Are these new failures? Do we know since when? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3545366&group_id=10894 |