Tcl Source Code

View Ticket
Login
Ticket UUID: 3587096
Title: win vista/7: "can't find init.tcl" when called via junction
Type: Bug Version: obsolete: 8.5.13
Submitter: oehhar Created on: 2012-11-14 10:46:51
Subsystem: 37. File System Assigned To: nijtmans
Priority: 8 Severity:
Status: Closed Last Modified: 2013-01-08 17:35:16
Resolution: Fixed Closed By: nijtmans
    Closed on: 2013-01-08 10:35:16
Description:
Platform: win vista/win 7
Tcl Versions: 8.5.13, 8.6.0rc0

The following error message arises, if wish86.exe is called with a path component with a directory junction with no "Directory list" right
This is the case for German Windows Vista when wish.exe is in the folder c:\programme (which is a juction to "c:\program files").

"Can't find a usable init.tcl in the following directories:
C:/programme/tcl8.6/lib/tcl8.6 C:/programme/tcl8.6/lib/tcl8.6
C:/programme/lib/tcl8.6 C:/programme/tcl8.6/library
C:/programme/library C:/programme/tcl8.6.0/library C:/tcl8.6.0/library"

--------------------------------------------------------------------------------
Unfortunately, I am not able any more to test this, as I applied the hotfix which changes that:
http://support.microsoft.com/kb/969986
I have not found any way to rewind that.
-------------------------------------------------------------------------------
The following test does not show this error, but a similar one. The shown error message complains about a not found tk.tcl.
Do the following steps (translated from german dialogs):
- you have a tcl installation in a path, say c:\test\tcl860rc0
- open an administrator dos box
- enter there:
  cd c:\test
  mklink /j tcl860rc0_junction tcl860rc0
- use the windows explorer, open the properties of the junctions, tab security:
- Press the continue button to open the "Rights for tcl860rc0_junction tcl860rc0" dialog box
- Select "Users" in the listbox "Graup and User names"
- Select the "Deny" checkbox for "Show folder contents"
  The attached image shows the german version of the dialog
- Press "Apply"
- Ceate a batch file with the following contents:
c:\test\tcl860rc0_junction\bin\wish86.exe
<EOF>
Adjust the name of the wish executable, if your name is different.
- execute the batch file.
It appears a message box with the following text:

"Can't find a usable tk.tcl in the following directories:
C:/test/tcl8.6.0/library/tk8.6 C:/test/tcl8.6.0/tcl8.6
C:/test/tcl860rc0_junction/lib/tk8.6 c:/test/lib/tk8.6
c:/test/tcl860rc0_junction/library"

------------------------------------------------------------------------
IMHO, one should introduce a "[file normalize ]" around the generation
of the parentDir variable in Line 370 of tclInterp.c:

The current code is:
set parentDir [file dirname [file dirname [info nameofexecutable]]]
to avoid this issue, one may use:
set parentDir [file normalize [file dirname [file dirname [info nameofexecutable]]]]
At least, this helps in my scripts to get rid of directory junctions related issues.

A sample session with the "c:\Programme" junction:
C:\test>c:\Programme\tcl8.6\bin\tclsh86t.exe
% info nameofexecutable
c:/Programme/tcl8.6/bin/tclsh86t.exe
% file normalize [info nameofexecutable]
C:/Program Files/tcl8.6/bin/tclsh86t.exe

---------------------------------------------------------------------
Unfortunately, in the upper test case, it fails.
Example session: (the upper example, but with tclsh86t.exe in the batch file:
c:\test\tcl860rc0_junction\bin\tclsh86t.exe

C:\test>c:\test\tcl860rc0_junction\bin\tclsh86t.exe
% info nameofexecutable
c:/test/tcl860rc0_junction/bin/tclsh86t.exe
% file normalize [info nameofexecutable]
C:/test/tcl860rc0_junction//tclsh86t.exe

Remark the double "//" - the path component "bin" disapeared.
---------------------------------------------------------------------
Related core list thread: http://code.activestate.com/lists/tcl-core/12335/
User Comments: nijtmans added on 2013-01-08 17:35:16:
Fixed now on core-8-4-branch, core-8-5-branch and trunk

oehhar added on 2012-12-13 16:49:31:
The patch proposed in tcl bug # 3092089 solves the issue for me.

See comment
Date: 2012-12-13 01:47:16 PST
Sender: oehhar
for details.

Thank you,
Harald

dgp added on 2012-11-15 19:57:35:
ferrieux is sometimes interested in, and always good at, solving puzzles.

Can you make any sense out of these findings?  Reproduce and solve them?

The [file normalize] workaround is apparently available, but unattractive if
it leaves the deeper problem unresolved and if it has the potential to upset
matters on other platforms.

oehhar added on 2012-11-15 16:32:24:
To your question, which command fails:
as there is no "error" part in the message, only file exists should say 0.

I tried it with an initialized wish and a fragment from the script in tclInterp.c (from line 389):

(bin) 1 % lappend dirs "C:/test2_junction/tcl860rc0/lib/tcl8.6"
C:/test2_junction/tcl860rc0/lib/tcl8.6
(bin) 2 % set tcl_library [lindex $dirs end]
C:/test2_junction/tcl860rc0/lib/tcl8.6
(bin) 3 % set tclfile [file join $tcl_library init.tcl]
C:/test2_junction/tcl860rc0/lib/tcl8.6/init.tcl
(bin) 4 % file exists $tclfile
1
(bin) 5 % source $tclfile
(bin) 6 % set errorInfo
can't read "::tcl_pkgPath": no such variable
    while executing
"foreach Dir $::tcl_pkgPath {
    if {$Dir ni $::auto_path} {
lappend ::auto_path $Dir
    }
}"

So, it is not reproducible by this method.

twylite added on 2012-11-15 16:13:51:
Could this be related to bug 3545366?  There have been a couple of past problems with file system link normalization.

oehhar added on 2012-11-15 16:05:50:
I can also easily demonstrate bug 3092089 with the setup of my last post.
If a path passes by a junction, the next path component is set to the empty string if this component exists:

To demonstrate, use the upper setup with c:\test2 and c:\test2_junction pointing to c:\test2

Start any wish and type:

(bin) 2 % file normalize c:/test2_junction/tcl860rc0
C:/test2_junction/
(bin) 3 % file normalize c:/test2_junction/tcl860rc0/bin
C:/test2_junction//bin

This does not happen, if the path does not exist:
(bin) 4 % file normalize c:/test2_junction/tcl860rc0/bin/junk
C:/test2_junction//bin/junk

oehhar added on 2012-11-15 15:58:54:
I rethought why the bug did not appear with the demonstrator.
It is due to the fact, that in my test folder, there is also the source distribution of tcl8.6.0 and this tcl8.6.0/library/init.tcl was used.

Thus I made a new try in a new folder which succeeded:
- cd \
. mkdir test2
  cp test2\tcl860rc0 \test2 (syntax incorrect, used explorer)
  mklink /j test2_junction test2
- windows explorer:
  - properties of test2_junction
  - page security
  - Button "Change" (with Admin sign)
    Windw "Permissions for test2_junction" opens
  - click "any" in user name pane
  - Click the deny checkbox for "Show Folder" (well translation may also be "list folder")
  - ok ok
- batch file with:
c:\test2_junction\tcl860rc0\bin\wish86t.exe
- start batch file. A box appears with:
"Can't find a usable init.tcl in the following directories:
C:/test2_junction/tcl860rc0/lib/tcl8.6
C:/test2_junction/tcl860rc0/lib/tcl8.6 C:/test2_junction/lib/tcl8.6
C:/test2_junction/tcl860rc0/library C:/test2_junction/library
C:/test2_junction/tcl8.6.0/library c:/tcl8.6.0/library"

twylite added on 2012-11-14 22:00:15:
I'm only following this conversation with half an ear, so please feel free to ignore this if it's not relevant:

If anything in the Tcl startup or in the distribution libraries (including resource finding scripts in msgcat, clock, etc.) expects or relies on any path returned by tcl::pkgconfig to be valid, then that logic is utterly, completely and unfixably(*) broken on all Windows platforms.

(*) There is a fix: remove any reliance on pkgconfig being right.

pkgconfig should only ever be used to discover the build configuration of a shell (and its libraries) for the purposes of building another extension to work with that shell (under the explicit assumption that you're on the machine that build the shell [or an identical setup] and that you installed the shell to the location that you specified in the build scripts).

Moreover if anything in the Tcl startup or in the distribution libraries attempts to use tcl::pkgconfig or an environment variable in preference to relative paths then there is a security hole that needs attention (a user could inject a script of their choice into an interp, even when filesystem access controls prevent that user from modifying the Tcl interp or libs).

dgp added on 2012-11-14 21:20:04:
You're demonstrating serious failure of basic Tcl functions
on a common platform.  Letting it go isn't my first choice.
Let's see if we can bring in some other Windows expertise
before giving up.  Asking mistachkin first, but feel free to pass
around to other helpful candidates.

oehhar added on 2012-11-14 21:11:12:
I am sorry, I can not help any more.
My system does not show the bug and I have no idea how to rewind the hotfix.

I have made many tries here, some are documented and all are failing somewhere.

I tried to build a version of tcl with symbols where the build fails.

So I propose to put this bug asleap as nobody can help.
Sorry,
Harald

dgp added on 2012-11-14 20:34:39:
Please drill down and determine why the code
as written is failing.  Is it [source]?  Is it [file exists]?
Let's drill all the way down to the real bug first, then
layer on workarounds if we still have to.

I'll be limited in what I can actually do here, since I
do not use the vista platform myself to reproduce
the report and test possible fixes.

oehhar added on 2012-11-14 17:46:57:

File Added - 456551: deny_list_folder.png

Attachments: