Support symlink creation

[jelly]

Our current implementation is an arbitrary symlink creation dialog

The target path can be edited to something else and is shown as an absolute path while the link name can't be an absolute path by only relative. (As the dialog prefills /home/admin).

This is confusing, because it made me think I should provide an absolute path in both inputs.

Symlink creation arbitrary creates a symlink under directory if directory is passed

Moving symlinks

Moving relative existing symlinks can break, do we show a warning?

[jelly]

Some more questions:

• Do we want to support relative symlinks? I am thinking we should not and treat this as a file manager. You make a link to something and then move this somewhere else.

[garrett]

Here's a comparison of all the sorts of links:

• absolute symlinks:
  • when the source is at a particular unchanging place and you want to reference it
  • moving the source (even renaming a parent directory) breaks the destination
  • useful for referring to system files
  • refers to the complete path, starting from /
• relative symlink:
  • when the source and destination are contained within the same parent directory
  • changing the parent of both source and destination does not break the link
  • useful for a project directory
  • relative path and may include parent directories as well "../", "../../", etc.
• hardlink
  • a copy of the reference to a data on disk (inode)
  • moving source and/or destination does not break the link
  • they're both files that point to the same data on disk
  • only works for files, not directories
  • deleting one file doesn't delete the data (until all are deleted)
  • when you edit, you're editing the data that the hardlink points to, so all "files" change their contents
  • can't be across filesystems
• reflink
  • similar to hardlink
  • when you edit a file that's a reflink, the content diverges between the two "files"
  • can't be across filesystems
  • only supported by some filesystems (btrfs, zfs, apfs, newer versions of xfs)
  • most copy commands now default to a reflink where supported

The important part is intent. Absolute is for referring to files outside of a project that will not move, whereas relative is for within self-contained directory trees (such as projects, git checkouts, etc.), which could possibly be reparented (renaming or moving the toplevel container directory). They're both valid uses of symlinks, and depending on what an administrator is using, they may want one or the other.

I guess we should probably show them untruncated and relative (so someone could see the actual files and path fragments that matter) and perhaps have an option to make it an absolute link in the background.

I'm not sure if hardlinks really make sense. I think they probably do not.

Reflinks, we get for free with a standard copy when on supported filesystems.

[garrett]

Taken all of the above into consideration, it looks like I need to design a new link modal.

We could put that on pause on the dialog for now and make linking make a "Link to" prefixed link like in GNOME.

However, I guess that would imply that it's an absolute link or some relative one that "smartly" updates when moved (which means we'd need to look at what the link links to and update it in the new location). The absolute link would be much easier to implement, even if it's less useful in most cases.

From https://stackoverflow.com/questions/8523159/how-do-i-move-a-relative-symbolic-link#8523293:

You can turn relative paths into full paths using readlink -f foo. So you would do something like:

ln -s $(readlink -f $origlink) $newlink
rm $origlink

and:

I noticed that you wish to keep the paths relative. In this case, after you move the link, you can use symlinks -c to convert the absolute paths back into relative paths.

...But this requires a command from the symlinks package, at least on Fedora, so it's out.

Someone in the thread mentioned this ln command as an alternative, which converts an absolute symlink to a relative one (by overwriting the absolute link with a relative one):

ln -srf $newlink

I don't see a way to do the opposite (relative to absolute), however, aside from the code block above.

So, moving/renaming a relative link could be:

1. convert to absolute link
2. do the move/rename
3. convert back to relative link

However, it's more complex than just moving an absolute link.

(I wonder if Nautilus handles this? Edit: Nope, it does not properly handle moving symlinks separate from moving origin files, apparently.)

[jelly]

In my opinion we should make a "create link" context menu item which makes a link for a directory or file "Link to X" which would be an absolute symlink.

If the link already exists, either we don't show the context menu or overwrite or append (n).

[allisonkarlitskaya]

I don't think we should have a UI option to create symlinks.

[jelly]

We concluded to drop symlink creation for now and we will re-visit this functionality later #419

[allisonkarlitskaya]

I don't think we should have a UI option to create symlinks.

I think I retract this opinion. Some of our users expect this feature.