Tcl Source Code

  When a filename contains a tilde character 'file exists' may falsely return zero.
  The bug occurs when the filename as returned from glob is used.
  Any call to 'file normalize' - even without using the returned value will cause a subsequent 'file exists' to correctly return 1.

  When the path is entered directly in tclsh, or hardcoded into a script, file exists correctly returns 1.

  set folder {/usr/local/test/} 
  set files [glob -dir $folder -type f *] 
  foreach f $files { 
      #puts [file normalize $f] 
      puts "$f exists: [file exists $f]" 
  } 


Simply create a text file with the name "~test.txt" in the test 
folder. 


With the 1st puts commented, the output is: 
/usr/local/test/~test.txt exists: 0 


With the puts uncommented, the output is: 
/usr/local/test/~test.txt 
/usr/local/test/~test.txt exists: 1 


Tested on FreeBSD  8.6b1.1 2009-06-14 checkout.

allow_comments - 1

Fix committed - was poor test hygiene in managing the working directory.

tests are broken, kbk has the fix.

allow_comments - 0

Reports on the chat indicate that tests
fileName-20.7,8 are failing on Windows.
Re-opened.

allow_comments - 1


Committed more radical patch to HEAD
for 8.6b2 that also removes some large chunks
of code complexity which had no obvious value.

fix committed for 8.5.8.  Should see the
tests fileName-20.7,8 now pass.

Version 2 of the patch also removes some
special workaround code in TclMakePathRelative()
that prevented it from doing the wrong thing when
the "tail" held a string starting with ~.  Since we no
longer permit that, we do not need the workaround.

Large comments questioning the rationale of some
bits of code, and pondering about their reform also
in the new patch.

File Added - 339935: 2806250-2.patch

Attached a patch for 8.5

File Added - 339822: 2806250.patch

The PATHFLAGS != 0 internal rep for path
values stores the path in two parts, a "head"
and a "tail".  Much of the code that operates
on this rep makes the assumption that the
"tail" is a relative path.  When a value starting
with ~ is permitted to get stored as the tail,
these assumptions no longer hold.

committed test fileName-20.7 to
all branches to test for this bug.

Sounds like a problem internal rep.

Title updated to remove reference to 'file normalize'.
It seems that various other operations on the string  (e.g subst) can be used to coax a bad path representation to do the correct thing.
e.g
set f [string range $f 0 end]

priority raised.
This issue has come up again on CLT.
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/2c8027298fe860f3/28cb705e1fb0e74d#28cb705e1fb0e74d

> cd /tmp/working/filenames.tcl

should read:

>cd /tmp/working

Verified that it does occur on Linux (CentOS) with 8.6b1.1
(but does not occur with 8.5.7 tclkit)

uname -a
Linux project-open-v33 2.6.18-53.1.21.el4 #1 SMP Tue May 20 09:34:19 EDT 2008 i686 i686 i386 GNU/Linux

This is the 3rd platform I've duplicated the bug on.
I'll explain it a bit more step by step - as I've found a couple of ways the bug can be hidden.

--------------------------------

create a folder structure  /tmp/working/examine

Make sure the examine folder contains only the ~test.txt  file
Save the following script as filenames.tcl - into the /tmp/working folder

set folder {/tmp/working/examine}
set files [glob -dir $folder -type f *]
foreach f $files {
    #puts [file normalize $f]
    puts "$f exists: [file exists $f]"
}


Make sure you run the script from within /tmp/working 
As mentioned in my other comment - if you run the script whilst your pwd is /tmp/working/examine - the bug will be masked.  

> cd /tmp/working/filenames.tcl
> tclsh filenames.tcl
/tmp/working/examine/~test.txt exists: 0


----------------------------------------------------------
Note that if you run it with the full path name to the script - you won't see the zero in the output.
ie it must be called as  'tclsh filenames.tcl'  not 'tclsh /tmp/working/filenames.tcl'

Another weird thing is that if you add the following line to the top of filenames.tcl - then suddenly the bug *does* appear when called as 'tclsh /tmp/working/filenames.tcl'

puts stdout "pwd: [pwd]"


It seems to me that it's possibly somewhat different to bug 2511011  because in this case we are supplying the -dir argument to glob and not using -tail,  so we are always dealing with the complete path.  As far as I can see - there should be no tilde/homedir substitution involved in this case.

Perhaps some detail is not getting
reported, and what's really happening
is some symptom of Bug 2511011?

Can't reproduce on Linux with the tip of
any active branch.

Verified that bug occurs on windows vista x64 with Tcl 8.6b1.1
Does not occur with an 8.5.2 tclkitsh on that platform.

The bug appears to also relate in some way to the current working directory.

If there is another copy of the file ~test.txt  within whatever directory [pwd] refers to - then [info exists] returns 1.

The tilde seems to somehow cause the path to refer to the working directory instead of the one being globbed upon.

(so for example - if the original script is placed in the same folder as the one with the test file and run from there - the bug is not apparent)