Tcl Source Code

This concerns Tcl  on Unix (Solaris 8, Solaris 9, RH
Linux Kernel 2.4.?):

When trying to open a file (e.g. [open $filename r])
with an absolute pathname containing symbolic links and
../ (parent directory), a wrong file is referenced:
e.g. if  /home/somedir is a link to /root/otherdir then
trying to open /home/somedir/../file opens /home/file
instead of /root/file

In Tcl 8.3.1 open worked as expected. The first Tcl
version which I can test and has the problem is 8.4.1

Logged In: YES 
user_id=32170

I don't know if I agree with dgp's comment that each
filesystem should have its own interpretation of '..'. 
Surely they should be the same?  (At least that's what's in
Tcl 8.5)

Logged In: YES 
user_id=80530

dropping priority since this
can't be "fixed" until the
differences of opinion about
the correct design of the
VFS layer laid out in 961646
are addressed.

this won't be fixed in Tcl 8.4.9.

Logged In: YES 
user_id=80530

This matter is related to 961646.

Both are rooted in the fact that
Tcl's Tcl_Filesystem layer is
imposing one interpretation of
 ".." in a path instead of leaving
it up to each (native) filesystem
to use its own preferences.

Logged In: YES 
user_id=72656

had to revert because the changes were not properly
isolated, and the 8.5 changes are a lot more spread out than
expected.  Don't know quite what to backport ...

Logged In: YES 
user_id=72656

backported for 8.4.6.

Logged In: YES 
user_id=72656

We will also need an 8.4-based patch.

File Deleted - 70250: 



File Added - 70363: linknorm.diff

Logged In: YES 
user_id=32170

Updated patch for cvs head.

File Deleted - 70242: 



File Added - 70250: linknorm.diff

Logged In: YES 
user_id=32170

Updated patch.  Needs testing on unix, but should then be
ready to go.

Jeff: could you test this please?

File Deleted - 70181: 



File Added - 70242: linknorm.diff

File Added - 70181: linknorm.diff

Logged In: YES 
user_id=32170

Please test the attached patch (to Tcl 8.5a0)

Logged In: YES 
user_id=32170

The bug is quite clear now.  TclFSNormalizeAbsolutePath
removes all '.' and '..' sequences before passing the path
to the platform-specific normalization code. But, the '..'
removal is done in a purely string-based way, with no
awareness of symlinks at all.

We probably need to remove that whole block of code (lines
149-173 of tclPathObj.c) and make each platform-specific
piece of code a bit cleverer.

This might actually improve performance, since it would
remove the need for a whole file split/file join pair in the
current approach (but replace it with more complex
platform-specific code).

Logged In: YES 
user_id=32170

Here's a simple example on Windows:

file mkdir tclfoo
cd tclfoo

file mkdir one/two/three
file link link one/two/three
file normalize link/../foo

# The result:
E:/tclfoo/foo
# It should be:
E:/tclfoo/one/two/foo

Logged In: YES 
user_id=32170

This behaviour is all down to 'file normalize', so if this
bug report is correct, you should be able to show that 'file
normalize' returns the wrong path for some input strings
containing ../

Can you please try to provide one or two examples?

Logged In: YES 
user_id=917954

The bug IS still ion 8.4.5. What I wanted to say that it
probably first occured between 8.3.1 and 8.4.1.

In your example /home/dist is a link to /tmp/dist
So /home/dist/../jeffh/.cshrc is /tmp/jeffh/.cshrc, not
/home/jeffh/.cshrc (try it e.g. with ls in any shell).
However, as long as you do not have a file
/tmp/jeffh/.cshrc, the open command from your example should
return an error "no such file or directory", instead of
opening the wrong file.

The same behaviour can also be found with a non-existing
directory in your pathname:
open /home/jeffh/nonexistentdir/../.cshrc
fails in 8.3.1 (correct), but succeeds in 8.4.5 (incorrect)

Logged In: YES 
user_id=72656

This works for me in 8.4.5 on linux:

ln -s /tmp/dist /home/
tclsh
 % open /home/dist/../jeffh/.cshrc
 file4

So this should have been checked against the latest release 
before submitting.