Symlinks are dereferenced
protist opened this issue · 9 comments
When used with symlinks, dragon points to the target, rather than the symlink itself.
touch a
ln -s a b
dragon *
Observed behaviour: dragging either a
or b
results in the output of a
.
Expected behaviour: dragging b
should result in the output of b
.
This is the behaviour I would expect, though there's a case for it to be an option. Moving a fixed symlink about isn't terribly useful.
I came across this when I was trying to upload some files. I had the original files scattered around my filesystem, and I had collated them into another directory using symlinks, concurrently giving them appropriate filenames. I dragged the symlinks into my browser, which uploaded the data fine, as expected, but the names were all wrong.
Another usage case where this might be a problem is if you were to embed an image into another file. I often embed a symlinked raster image into, say, Inkscape. If I then need to modify the original file, I just change the symlink to point at the new, modified file. Similarly so when I reference images in LyX/LaTeX.
In general, I can't think of a case where I'd want it deferenced, or if there's any advantage to do so, but perhaps that's just my usage though.
I also would also have expected path names to be left unchanged. Since the interface is CL, users who want the path normalized in some way can easily throw in a realpath
etc. invocation themselves.
Okay, since this may be passed as a URI it must be at least absolute. I’d recon the least surprising way to achieve this would be to prepend the CWD and canonicalize without resolving symlinks.
Fixing #2 also fixes this, since GIO will canonicalize the path, but will leave symlinks untouched.
@eigengrau Your commit partially works. I can click on b
, and now dragon leaves the symlink untouched, which is great. However, when I try to drag b
, dragon still outputs a
instead.
@protist I cannot reproduce this yet. Did you accidentally run your globally installed build of dragon
instead of the binary built from git, by any chance?
When I run this (from 7716c30):
touch a
ln -s a b
./dragon --verbose a b
Dragging b
into a dragon --target
will print:
Writing as URI: file:///home/seb/dev/c/dragon/b
And the --target
instance also receives this URL.
Oops, apologies. I was testing by dragging into a program that automatically dereferenced the symlink. I can confirm that your code works perfectly! Thank you!
Yeah, this works for me in the tests I’ve thrown at it. It’s merged in now.
There is a trade-off here: if you use it for actual file manipulation (e.g. drag into a file manager), it’s going to copy the symlink and not the file, which isn’t very useful. Dragging to a browser or something is probably the more common use case so I’ve merged it, but I might add a --follow-symlinks
option or something for the other case.