tk_getOpenFile in linux gives another path as selected?

[Juge]

Well, in a sense it actually gives the correct path but we have somewhat strange configuration in our system. We have partitition that are automounted under address /net/something/something_else/share and then they are softlinked to /share

If I use tk_getOpenFile and navigate to /share/subdirectory and select a file I get as a return the mounted path: /net/something/something_else/share/subdirectory/example.txt

Sofar so good, but somehow later the application can not see this path it is only able to access the linked path /share

Is there a way to get the linked path instead of the system path? I could write a string map, but I do not want to cover all eventualities of the automounting scenario if I can avoid that. Not to mention I have no rights to change the system configuration.

[Brad Lanam]

tk_getOpenFile does not run a 'file normalize' on the path (I just checked),
so I am not sure why you are getting the normalized path back.

I'm also not sure how a symlink can have access but not the network
path.

How about:
regsub {^/net/[^/]+/[^/]+/share/} $mypath /share/ mypath
As long as your sysadmins keep the same naming convention, this should
last a while.

I would like a 'file normalize -keepsymlinks' function that does not convert
the symlinks. For user interaction, it is useful to have the
path normalized, but keep the user's view.

[Matthew Hiles]

This might be more a problem with automounter. Does the path get automatically) unmounted while you're using the application, after it has accessed a file? I use this same exact setup (auto mount path + symlink) and come across similar issues in other software. Can you recreate the problem, then access the automount path from another spot (just cd into from bash) and then does the issue resolve?