Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resolver: dir namespace with symlinks #2656

Open
markus2330 opened this issue May 1, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@markus2330
Copy link
Contributor

commented May 1, 2019

Steps to Reproduce the Problem

mkdir -p /tmp/world/folder /tmp/other
cd /tmp/world
kdb set dir/tests/hello world
cd /tmp/other
kdb set dir/tests/hello other
ln -s ../world/folder folder
cd /tmp/other/folder
kdb get dir/tests/hello

Expected Result

That "other" is printed because I was in /tmp/other.

Actual Result

"world" is printed.

System Information

  • Elektra Version: master
@kodebach

This comment has been minimized.

Copy link
Contributor

commented May 2, 2019

Did you try using an absolute path with ln? In my experience Elektra is not very good with relative paths...

@markus2330

This comment has been minimized.

Copy link
Contributor Author

commented May 2, 2019

Did you try using an absolute path with ln?

You mean:

cd /tmp/world
kdb set dir/tests/hello world
cd /tmp/other
kdb set dir/tests/hello other
ln -s /tmp/world/folder folder
cd /tmp/other/folder
kdb get dir/tests/hello

? It does not make a difference. I am afraid we have a problem here which cannot solved with POSIX. getcwd can and usually does "jump" to symlinks. (Without any information where it came from.)

We could execute pwd but this is somehow a hack. Btw. git has the same problem.

In my experience Elektra is not very good with relative paths...

Did you make a bug report?

@kodebach

This comment has been minimized.

Copy link
Contributor

commented May 2, 2019

I had another look at your problem and I think this is not a bug, but a decision we need to make.

The base scenario is:

  • You cd into a symlinked folder.
  • This folder does not contain a KDB dir namespace, i.e. any kdb get call to the dir namespace has to traverse up the file hierarchy.

Now the decision we need to make is do we:
A) traverse upwards from the target folder (in your example /tmp/world)
B) traverse upwards to the location of the symlink (in your example /tmp/other)

Both of these options seem valid to me and are purely a matter of preference. If we want to have option B), we could use getenv("PWD"). If this is not set, even the pwd utility uses the physical path (according to the POSIX spec).

@markus2330

This comment has been minimized.

Copy link
Contributor Author

commented May 5, 2019

In my situation the option B makes much more sense. My folders look like this:

  • projectA <- containing .dir
  • projectA/scripts
  • projectB <- containing .dir
  • projectB/scripts

The folder scripts is shared, so it is symlinked from one project to the other. As workaround I now avoid changing to this directory and I have put an invalid configuration into scripts (to get an error if I accidentally have been in the folder).

`getenv("PWD")

Yes, this would work but it would also introduce another source of error (PWD sometimes is inconsistent). And we would be back to the discussion of #734.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.