I have a document that, after I’ve updated it, gets saved as “filename_YYYYMMDD.odt” and when I make it available to others, it’s via a symbolic link “filename.odt”. Dolphin complains when I attempt to copy the file to another location using the link; at least it does when the target is a VFAT-formatted USB drive (which, obviously doesn’t understand the concept of symbolic links). So instead of dragging “filename.odt” to the target location, I have to drag “filename_YYYYMMDDDD.odt” and then rename it. I never had to do this under Gnome/Nautilus. Is there a way to configure Dolphin to allow the symbolic link to be used when I drag-n-drop? I haven’t seen anything in the Dolphin Preferences to modify this behavior.
BTW… It doesn’t work using “file manager” either. So I’m guessing that this is a more than likely KDE restriction than a Dolphin-specific problem because from the shell I can issue
cp symlink-to-file usb-target-dir/
without any problem to create a file (not a symlink) on the USB device named “symlink”. (I’ll apologize up-front if those abbreviations don’t make sense?)
I’m trying to understand what you are trying to accomplish. So filename.odt is a symlink to a file filename_YYYYMMDD.odt. This filename is I assume saved on a let’s say daily basis with a different name. Is that correct? if yes the link you expect to point to the new file every time you saved a new file. Am I lost in figuring out what you want? for sure. Try to have a step by step explanation as it is hard to figure out what you tried and possibly that’s why nobody tried to figure out your train of thought yet.
I agree, we are not clairvoyant, nor should you assume anybody else is doing things as you are doing them and thus will understand. That does not mean that you are doing things wrong, but simply, every assumption that we have to make about what you see/do/want can be wrong (more then 50% change ?) and thus advice based on more then about three assumptions will certainly be wrong.
Try to show/prove what you have and do with real terminal emulator texts (betweenCODE tags, you get them by clicking the # button in the toolbar above the post editor). Use commands like
ls -l
to show things and not vague and incomplete stories like “cp symlink-to-file usb-target-dir/” because my assumption is that that is not exactly and precise what you typed when doing that command.
I had a feeling my explanation wasn’t going to be clear enough…
The actual file is updated occasionally and saved with the modification date in the filename, when it is, I redefine the symbolic link so that others only need to know about the presence of “filename.odt”. (Aside: the file may not be in “.odt” format; it’s more than likely going to be “.doc” or “.pdf” but I highly doubt the file format is the real problem here.) But if anyone tries to copy the file by accessing it via the symlink, the GUI file managers all fail. NOTE: The copy only seems to fail when the target is a VFAT-formatted device. Opening up an xterm and copying the file via the symlink the operation is successful regardless of the type of target device. So, apparently, the GUI file managers – at least all the ones I’ve tried so far – are not even bothering to detect that the source of the copy operation is a symbolic link and using the actual target of the link as the source file. What appears to be happening is that the GUI sees that the source is a symlink and if the target is a VFAT-formatted USB drive it fails because the target device doesn’t support symbolic links. What I would have thought should happen would be that the GUI file manager would see that the target device doesn’t support the symlink and would fall back to copying the actual file (the target of the link) – but using the symlink name for the output file – rather than trying to reproduce the symlink on the USB drive. This would be consistent with what happens at the shell level. If the GUI wanted to pop up a dialog asking for a confirmation that copying the actual file instead of the link was “OK” that, IMHO, would be better than failing and then issuing a notification that the copy operation is complete when it never actually took place.
Unless I’m missing some configuration option in Dolphin, file manager, and the other GUI applications like that it looks like I’m stuck telling others to use the shell to get a copy of the file. Is there a GUI file manager that’ll copy the actual file to a USB device rather than failing when it cannot create a symbolic link? (If there is, I could instruct the users to set that as their default file manager and it’d all be good.)
The above works. But if you select all the files (highlight “*.file”) in Dolphin and drag them to the USB device and select “copy” in the mini-menu that pops up, copying the symlink fails (as I noted above and as expected). The notification incorrectly tells you that three files were copied. (Unfortunately, I really cannot use hard links to point to the files as many of them will reside on different filesystems.)
Hoping this is more clear now…
BTW: I haven’t found anything in the KDE bug list about this (searching through that is pretty difficult; there’s so much there which in itself isn’t very encouraging) so it might very well be an unresolved bug. If folks here confirm that they are also unable to get this to work, I’ll file a report.