Tcl/Tk 8.6.6 Observations

Incompatibility?

Just SDX'd the same sourcecode with runtime tclkit-cli-8_6_6-x86.exe instead of tclkit-cli-8_6_5-x86.exe and tested some call:

could not get modification time for file "C:/Users/matthiasu/usr/pgm/tcl/usr/Src/hr/hr.exe/bin/notepad2"
    while executing
"file mtime $prog"
    ("foreach" body line 10)
    invoked from within
"foreach prog [glob -nocomplain -dir $progDir *] {
         if {[string match -nocase $_args(-glob:) $prog]} {
            if {[file executable $prog]}..."
    ("foreach" body line 3)
    invoked from within
"foreach subDir {bin tools} {
      set progDir [file join $::starkit::topdir $subDir]
      foreach prog [glob -nocomplain -dir $progDir *] {
        ..."
    invoked from within
"if {$_args(-showprogs)} {
   # es fehlt: Unterscheidung Dirs/files/DATs etc.
   foreach subDir {bin tools} {
      set progDir [file join $::starkit::..."
    (file "C:/Users/matthiasu/usr/pgm/tcl/usr/Src/hr/hr.exe/lib/app-main/app-main.tcl" line 333)
    invoked from within
"source C:/Users/matthiasu/usr/pgm/tcl/usr/Src/hr/hr.exe/lib/app-main/app-main.tcl"
    ("package ifneeded app-main 0.3" script)
    invoked from within
"package require app-main"
    (file "c:/Users/matthiasu/usr/pgm/tcl/usr/Src/hr/hr.exe/main.tcl" line 10)

The previous "build" returns the expected result...:

c:\Users\matthiasu\usr\pgm\tcl\usr\Src\hr>hr_ -showp
  ...
  bin       6144 02.03.06 17:30:10 askpw.exe
  bin        900 12.08.98 01:07:00 cal.com
  bin       8704 20.06.03 17:57:42 cat.exe
  bin       1939 01.06.10 16:51:06 chckinst.bat
  bin      38400 11.12.08 12:54:04 CleanAfterMe.exe
  bin       6144 30.07.06 10:16:40 cliptext.exe
  bin       3584 18.03.06 00:28:56 copyacls.exe
  bin      46592 25.01.09 10:15:32 cports.exe
  bin      21108 21.12.99 06:58:04 cusrmgr.exe
  bin       3072 19.03.07 15:47:42 cut32.exe
  bin       2560 11.11.03 22:34:26 dellater.exe
  bin       7680 12.07.06 09:27:10 devmgr.exe
  bin      22016 09.01.06 12:28:36 difftool.exe
  bin      13824 13.10.06 12:07:46 diskfree.exe
  bin      58880 14.12.98 15:29:50 eldump.exe
  bin       7168 19.03.07 15:47:42 exelist.exe
  bin      33280 25.03.08 09:39:14 fart.exe
  bin       4096 24.05.07 02:38:06 fileinfo.exe
  bin       3072 19.03.07 15:51:50 gethost.exe
  bin      35840 23.06.07 12:11:14 gzip.exe
  bin      10752 11.07.07 09:17:22 hostaddr.exe
  bin       3072 05.11.08 15:17:12 joindomain.exe
  bin      36864 10.11.99 23:00:00 less.exe
  bin       1748 23.03.10 10:35:10 machines.bat
  bin       4096 19.03.07 15:52:58 movent.exe
  bin      26112 16.08.01 03:20:00 netview.exe
  bin <dir>      01.01.70 01:00:00 notepad2
  bin      38400 01.01.09 02:27:20 OpenedFilesView.exe
  bin      15360 02.12.98 17:07:48 passwd.exe
  ...

Have to inspect the source code to see what's going on.... For explanation: The command is part of a program which contains in it's VFS lots of other programs, which are simply listed with the switch -showprog.

APN Likely caused by this check-in by me that adds support for atime/mtime etc. for special Windows files like CON:. As per the manpage for file atime/mtime commands,

If the file does not exist or its modified time cannot be queried or set then an error is generated.

On Windows, a mtime of 0 should never be generated (hence the code is under a #ifdef Windows) since a modification time of 1970 is impossible, but clearly I did not take into account VFS implementations doing this. For practical reasons, might be best to accept the bogus time of 0 as valid and change documentation accordingly.

MHo Additional Info: The original timestamp of the directory notepad2 used to create the VFS is 05.10.2014..... very mysterious. Could it be that file mtime no longer works for directories within a VFS?

DKF: It definitely should work. If it doesn't, that's a genuine regression.

APN: Not sure exactly what should work means. The 8.6.5 version returns 0 (hence the 1970 timestamp above). Does that construe "working"? Or does working mean the VFS should maintain a real time stamp?

MHo However, no file or dir has such a timestamp...:

c:\Users\matthiasu\usr\pgm\tcl\usr\Src\hr\hr.vfs\bin>dir n*.*
 Datenträger in Laufwerk C: ist Windows
 Volumeseriennummer: FCEC-BFEA

 Verzeichnis von c:\Users\matthiasu\usr\pgm\tcl\usr\Src\hr\hr.vfs\bin

16.08.2001  03:20            26.112 netview.exe
05.10.2014  00:02    <DIR>          notepad2
               1 Datei(en),         26.112 Bytes
               1 Verzeichnis(se), 1.427.627.827.200 Bytes frei

c:\Users\matthiasu\usr\pgm\tcl\usr\Src\hr\hr.vfs\bin>

DKF: Exactly. I don't know why that isn't working, and I had no reason to expect it to not work. It's supposed to work; it's our intention that it works. That it does not, that is a wrong thing. This is a bug and it hasn't been properly reported yet (as of 2016-08-20T14:00Z). Is it possible to make this bug exhibit itself with plain Tcl? That would help hugely with making an actionable bug report .

MHo 2016-09-16:

# Steps to reproduce the error without dependencies other than sdx and tcl 8.6.6:
# echo puts [clock format [file mtime [file join $starkit::topdir newsubdir]]]>test.tcl
# sdx qwrap test.tcl -runtime tclkitsh.exe
# sdx unwrap test
# -> now we have a test.vfs folder
# cd test.vfs
# md newsubdir
# cd ..
# sdx wrap test -runtime tclkitsh.exe
# ren test *.exe
# test
#
#  could not get modification time for file "C:/Users/matthiasu/usr/pgm/tcl/usr/Tst/8.6.6_test/test.exe/newsubdir"
#      while executing
#  "file mtime [file join $starkit::topdir newsubdir]"
#      (file "C:/Users/matthiasu/usr/pgm/tcl/usr/Tst/8.6.6_test/test.exe/lib/app-test/test.tcl" line 3)
#      invoked from within
#  "source C:/Users/matthiasu/usr/pgm/tcl/usr/Tst/8.6.6_test/test.exe/lib/app-test/test.tcl"
#      ("package ifneeded app-test 1.0" script)
#      invoked from within
#  "package require app-test"
#      (file "c:/Users/matthiasu/usr/pgm/tcl/usr/Tst/8.6.6_test/test.exe/main.tcl" line 4)
#

Just opened Ticket with UUID bc8467d6fdc512c9fc8e3c6e161cc300fea06116 for this bug ;:-)