tcl tells current directory would not exist

[MartinLemburg@Siemens-PLM]

Hi,

today I had a strange effect of trying to work in a directory, which is a symbolic link to another Directory from a share on my NAS.

(I created the symbolic link on my Win10 System with the mklink commandline utility.)

I forgot that the NAS is shutdown during the day and tried to step into the referenced Directory via the symbolic link, got an error message, turned the NAS on and continued the work.

Then I wanted to use a tcl script to do some sorting/moving/renaming of files, which complained, that the current working Directory does not exist.

Here the Output of the dir command:

C:\Users\Martin\Pictures>dir ".\NAS *"
Datenträger in Laufwerk C: ist Windows7_OS
Volumeseriennummer: 0E7F-BC8B

Verzeichnis von C:\Users\Martin\Pictures

16.12.2017 23:23 <SYMLINKD> NAS Pictures [\\DBDDHKPNAS\Multimedia\Pictures]
0 Datei(en), 0 Bytes
1 Verzeichnis(se), 342.118.961.152 Bytes frei

Here an example from the tclsh prompt:

C:\Users\Martin\Pictures\NAS Pictures>tclsh
% file exists [pwd]
0
% cd ..
% file exists [pwd]
1
% pwd
C:/Users/Martin
% cd "NAS Pictures"
% pwd
C:/Users/Martin/NAS Pictures
% file exists [pwd]
0
% cd ..
% file type "[pwd]/NAS pictures"
could not read "C:/Users/Martin/NAS pictures": no such file or directory
% cd "NAS Pictures"
% set d [pwd]
C:/Users/Martin/NAS Pictures
% cd ..
% file type $d
could not read "C:/Users/Martin/NAS Pictures": no such file or directory
% file link $d
could not read link "C:/Users/Martin/NAS Pictures": no such file or directory

Any Explanation for this behavior?

Best regards

Martin

[MartinLemburg@Siemens-PLM]

BTW tcl does not even find files.

Here the result of the dir command (without 413 lines of file names):

C:\Users\Martin\Pictures\NAS Pictures\Lutz>dir *.jpg

Datenträger in Laufwerk C: ist Windows7_OS
Volumeseriennummer: 0E7F-BC8B

Verzeichnis von C:\Users\Martin\Pictures\NAS Pictures\Lutz

...
413 Datei(en), 783.093.170 Bytes
0 Verzeichnis(se), 1.408.879.546.368 Bytes frei

Here the result of tcls glob:

C:\Users\Martin\Pictures\NAS Pictures\Lutz>tclsh
% set jpgs [glob *.jpg]
no files matched glob pattern "*.jpg"
% pwd
C:/Users/Martin//NAS Pictures/Lutz

[MartinLemburg@Siemens-PLM]

While having used ActiveTcl 8.6.4 distribution, I tested now with the currently available 8.6.7 Distribution - with the same result:

C:\Users\Martin\Pictures\NAS Pictures\Lutz\Sicherheitskopie>tclsh
% info patch
8.6.7
% glob *

no files matched glob pattern "*"

% dir

Datenträger in Laufwerk C: ist Windows7_OS
Volumeseriennummer: 0E7F-BC8B

Verzeichnis von C:\Users\Martin\Pictures\NAS Pictures\Lutz\Sicherheitskopie

28.12.2017 21:08 <DIR> .
28.12.2017 20:40 <DIR> ..
28.12.2017 21:12 <DIR> 2017
28.12.2017 21:08 <DIR> 2016
0 Datei(en), 0 Bytes
4 Verzeichnis(se), 1.399.125.397.504 Bytes frei

[Brad Lanam]

That's a known problem.
Tcl does not support Windows symlinks.

http://core.tcl.tk/tcl/tktview/972c35d41d10fa76718d
http://core.tcl.tk/tcl/tktview/218155ffffffffffffff

There are more, but that ticketing system doesn't have a good search utility.

[MartinLemburg@Siemens-PLM]

Thanks for this Information Brad!

What confuses me, is, that I already worked on the Symbolic Link before using a command line and the same tcl script to sort/rename/move files.
The only difference is, that the folder referenced by the Symbolic Link was present at Startup, while this time the NAS was turned on after realizing, that the Symbolic Link can't be resolved, because the NAS was shutdown.

I'll take a look at the bug Reports and add Information, if necessary.

Best regards

Martin

[MartinLemburg@Siemens-PLM]

Am Freitag, 29. Dezember 2017 01:13:35 UTC+1 schrieb Brad Lanam:

What read at one of the tickets is, that administrative rights are nighted to use Symbolic Links. No way, creating those Needs sufficient permissions, but using them, as far as the target is accessible with the rights of the current user, does not Need administrative rights.

Sincerely I can't add comments to one of the two tickets, nor do I have the sufficient permissions to create a new ticket related to this issue.

[MartinLemburg@Siemens-PLM]

Another issue (eventually)?

C:\Users\Martin\Pictures\NAS Pictures>tclsh

% pwd
C:/Users/Martin//NAS Pictures
% file normalize .
C:/Users/Martin/NAS Pictures
% file exists [file normalize .]
0

% file exists [pwd]
0
% cd ..

% pwd
C:/Users/Martin
% glob NAS*
couldn't read directory "C:/Users/Martin/NAS*": permission denied
% glob -types d -- *
couldn't read directory "C:/Users/Martin/*": permission denied
% glob *
couldn't read directory "C:/Users/Martin/*": permission denied

The current working Directory contains doubled slashes. Which is eventually another issue.

But strange is, that the process tclsh.exe, which is started with the user Martin does not seem to have the rights to list the Contents of my Profile Directory "%userprofile%".

Äähhm - permission denied?

Some thoughts about how I made the Symbolic Link:
1. opeend cmd.exe as Administrator
2. used "cd %USERPROFILE%\Pictures
3. used "mklink ..."

So the created Symbolic Link is inside the "user Profile" of the Administrator account, not inside mine.

So opening a tclsh in the "NAS Pictures" directory as admin causes no, absolutely no Troubles in accessing the directories and files inside this Directory.
Opening the tclsh as other user in the admin's "NAS Pictures" Directory, does not give a sign of insufficient permissions, but strange effects of not existing Contents.

Creating the Symbolic Link in the correct Directory, in "my" user profile, causes no troubles, so that the sort/rename/move tcl script runs without Troubles.

Please take my excuse, that I made my error, my confusing to yours.

The only Thing I would like to see different, is to have concrete error messages, instead of strange results of the file System API.

Best regards and shame on me

Martin