Symlinks are dereferenced

[mwh]

Symlinks are dereferenced

[mwh]

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.

[mwh]

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.

[protist]

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.

[eigengrau]

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.

[eigengrau]

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.

[eigengrau]

Fixing #2 also fixes this, since GIO will canonicalize the path, but will leave symlinks untouched.

[protist]

@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.

[eigengrau]

@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.

[protist]

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!