How to create a relative symlink which works across PC

symlink

I have the following directory structure to start with

~/a/bin
~/a/src -> /home/user/b/sync/src

I created a symlink

cd ~/a/src
ln -s ../bin bin-xyz

now bin-xyz is a broken link, and there is no way of cd-ing into it.

What i am looking for?

How to create a symlink inside a symlinked folder such that the relative path is not broken. For example,

 cd ~/a/src/bin-xyz

 cd ~/b/sync/src/bin-xyz

should work provided that there is bin directory in ~/a/ or ~b/sync/

Why i am looking for this ?

I am syncing ~/b/sync/src across machines, where ~/a/ is my workspace in both the machines but the user name of the machines differ. So, having a relative path that works means an easier work-flow for me.

I am using bittorent sync for syncing.

Thanks 🙂

Best Answer

now bin-xyz is a broken link

The reason for that is hopefully obvious: Either .. has to refer to the actual parent directory or else it would be completely ambiguous.

Since ~/a/src -> /home/user/b/sync/src, I presume with that as $PWD and ln -s ../bin bin-xyz you're trying to link /home/user/b/sync/src/bin-xyz to /home/user/a/sync/bin. In which case you should just use absolute paths:

 ln -s /home/user/a/sync/bin /home/user/b/sync/src/bin-xyz

The reason ln doesn't fill in the .. blanks in this regard is that it, unlike your current shell, has not been tracking your movement and has no way to know that by .. you meant something other than the real parent directory.

It's (maybe?) implied in your question that you can't do this because there are actually two different systems involved. That implies either a network share is mounted or you use the same block device with both, implying in turn an XY problem -- can't solve that without more details.

Related Solutions

Linux – How to make a variable symlink ? (or something similar)

For those people viewing this more recently, I've written a small FUSE filesystem called HomeFS that forwards calls to a directory relative to the calling users' home directories.

That is, if you have a user Tyler and a user Sarah with a HomeFS mountpoint at /usr/share/bigsoft/config and a relative directory of .config/bigsoft, when Tyler does ls /usr/share/bigsoft he will see the contents of /home/tyler/.config/bigsoft and Sarah will see the contents of /home/sarah/.config/bigsoft.

Primarily, this is to work around proprietary software which insists its variable files be in some 'install directory', like how some Windows software tends to work.

Unable to stat symbolic link to file

Your answer lies in the first output you provided:

$ stat /home/jzhu/other
  File: `/home/jzhu/other' -> `/root/other/'

This shows that /home/jzhu/other is a symlink to /root/other.

So basically to access anything in /home/jzhu/other/ you are going to need access to /root/other. This means that your user must have execute permissions on both /root and /root/other.

Next lets go on to this command:

$ stat /home/jzhu/other/
stat: cannot stat `/home/jzhu/other/': Permission denied

The reason why this fails and the one above works is because of the trailing /. On any command which works with a path, if the final component of that path (eg: other) is a symlink, and the path ends with a trailing /, then any system calls to operate on that path will try to dereference the symlink, and operate on what the symlink points to instead of the symlink itself.

Solutions:

There are 2 possible solutions to this.

1. Change permissions on `/root/other`:

As mentioned, add execute capability to both /root and /root/other. You can do this with basic or extended filesystem attributes.

You can add the jzhu user to the root group (usermod -a -G root jzhu) and add group execute to the path (chmod g+x /root; chmod g+x /root/other).
This isn't an ideal solution as it grants your access to anything restricted to the root group.
Use filesystem ACLs.
```
setfacl -m u:jzhu:x /root
setfacl -R -m u:jzhu:x /root/other
setfacl -d -R -m u:jzhu:x /root/other
```
This makes it so that your specific user gets execute access to /root/other and anything inside it.
It's still not ideal as if these resources are shared, they shouldn't be in root's home directory.

Note that in both these solutions we only grant the execute (x) bit. The execute bit is needed on a directory for a user to access anything inside that directory. However you also need the read (r) bit to be able to list (ls) the directory. Meaning that without the read bit, you'll have to know exactly where in /root/other the files are. If you want to allow read, just change the x in the last 2 setfacl commands to rx (for example, -m u:jzhu:rx).

2. Move the resources outside `/root/other`.

This is the preferred solution. You can either get rid of the symlink at /home/jzhu/other and create a directory in it's place, or put them in a shared location somewhere else on the system (without knowing what it is, I can't recommend a good location though).

The reason this is the preferred solution is that if these resources are shared among users, then they don't belong to a specific user and shouldn't be in that user's home directory.