quick-symlink

quick-symlink copied to clipboard

Request of additional actions

1. Ability to specify hard vs soft symbolic link type
2. Option to use relative or absolute paths or combination of for target/destination
   1. Enables support for cross-device file systems
3. Action panel for existing symbolic links
   1. (if broken) process to browse finder for 'Find/fix missing target'
   2. Modify existing paths and symbolic link features

---

Thoughts or reservations?

Dear Zach Gover, Thank you for your interest and interesting suggestions for expanding the functionality. I'll try to answer the points below:

1. "Ability to specify hard vs soft symbolic link type" - I plane to add this feature in the nearest future. I want to implement it as another menu item or through a sub menu. At the moment in mac os 10.14 it is precisely possible to create hard links from the context menu. I think I will add this feature soon. 2 and 3 it is not yet clear how it should look in the end, but I promise to think about it. The application itself was conceived as a very simple little utility, which I developed primarily for my needs. Therefore, I did not think about the functionality that you suggested. But I promise to think about it and decide what and how to realize it.

Dear Zach Gover, I have completed your suggestions for functions in the TODO file (development plans) - https://github.com/ololx/quick-symlink/blob/main/TODO.md:

- [ ] Develop additional `Finder extension`  which allows to create a `hard links` for selected folders and files via contextual menu.
- [ ] Develop the action panel for created symbolic links  and hard lonks (in the app window): 
  - [ ] a) (if broken) process to browse finder for 'Find/fix missing target'
  - [ ] b) Modify existing paths and symbolic link features

Thank you for your interest in the project. I thinking we can close this Issue, if you do not mind.

@ololx What is your position on option to use relative paths vs absolute?

@zgover Could you be so kind as to clarify what you mean? Because the created symbolic link now has the absolute path to the original.

Note that the root folder of the disk (where installed OS X) is not written and is indicated by writing a special character "slash" (/) at the beginning of the path.

@ololx let me demonstrate using ln cli

Target file: /Users/zgover/Documents/test.txt

Absolute example

To make an absolute soft symlink

Working dir: /Users/zgover/Documents

ln -s "$(pwd)/test.txt" "$(pwd)/example-dir/test-abs.txt"

Result below ⇩⬇︎

Relative example

To make a relative soft symlink

Working dir: /Users/zgover/Documents/example-dir

ln -s ./../test.txt ./test-rel.txt

Result below ⇩⬇︎

Final result

So now the example-dir should look like below ⇩⬇︎

Purpose

The general purpose of this is to make symbolic links within network drives (e.g. SMB, NFS, etc.,). While currently it is fixed to absolute paths, therefore when creating symlinks on an SMB share to a target which is also on the same share the resulting symlink is below ⇩⬇︎ (the destination fails if you're not on machine which created it because the absolute path is using the path of the currently mounted network volume)

Current result (network share)

Working dir: /Volumes/ReadyNAS/zgover/data

lrwxr-xr-x   1 zgover  staff    32 Aug 21 00:21 test.txt -> /Volumes/ReadyNAS/zgover/data/example-dir/test.txt

@zgover This is really interesting case. Can you give an example of a relative path that you would like to see for "lrwxr-xr-x 1 zgover staff 32 Aug 21 00:21 test.txt -> /Volumes/ReadyNAS/zgover/data/example-dir/test.txt"?

I think the main problem here is the different name of the mounted disk on another machine? Then this problem is solved by the feature you proposed - correcting the paths of the created links so that you can correct the beginning of the path on another machine (in your case / Volumes / ReadyNAS to the one that is relevant for this machine)

or you want to replace directories with ../ when is created the link in same super directory with target file or directory? For instance: lrwxr-xr-x 1 zgover staff 32 Aug 21 00:21 test.txt -> ./example-dir/test.txt

I added this point into TODO for the considered case - https://github.com/ololx/quick-symlink/blob/main/TODO.md:

- [ ] Optional feature - use relative path instead absolute path in symlink target URL (if target and link located in one volume)

@ololx cool let's keep the issue open until resolved to track progress in PR's and commits.

Hi, @zgover, I didn’t create a pull request for the release 0.8.0 (add the extension for hard links creation); so I left this comment here.

Could you be so kind to watch the v0.8.0 release and tell me about following: 1 - is relative path implemented in symbolic links as you suggested in the issue? 2 - is the extension for creating child links implemented as you suggested in the issue?