This is added from the brainstorm forum due to popular support. The original message has been copied below. "I can't believe that this hasn't been raised before but a quick google didn't produce any useful results. When I drag & drop files using Dolphin I get the offer of Move, Copy or Link but the Link option generates a symbolic link not a hard link. Now I fully realise that people moving from Windoze won't know what I'm talking about but those of us who've been using *nix for some time know what hard linking is and I, for one, would like to be able to use it without dropping to the CLI or having to create a special action and get it to work in the Context (RMB) menu. My suggestion would be to have this as an optional entry in the Copy/Move/Link dialogue which is not present by default but can be added if required. Obviously enough hard linking only works within the same file system and so it should only be offered when drag and dropping files within a single file system. Since the term 'Hard Link' would confuse things with 'Symbolic link' I'd suggest that we use the term 'Clone' for a hard link whilst retaining 'Link' for the symbolic link." Reproducible: Always
Thanks for the report. I'll reassign this to KIO, because KIO does not support the creation of hard links AFAIK. (BTW, the Move/Copy/Link menu is not part of Dolphin at all, but of lib/konq. However, I think that lib/konq does not have its own product at bugs.kde.org). (In reply to comment #0) > Since the term 'Hard Link' would confuse things with 'Symbolic link' I'd > suggest that we use the term 'Clone' for a hard link whilst retaining 'Link' > for the symbolic link." This is a no-go from my point of view. I don't expect that many users will understand what "Clone" means. BTW, please report feature requests with the severity 'wishlist'. Moreover, it would be good to provide a link to the forum for Brainstorm ideas. Reading the comments of other forum users might give some further insights why this feature is considered necessary. I had always assumed that users who know the difference between soft and hard links prefer to use the command line for many tasks, and don't need a file manager to create hard links. Understanding the reasons for this request and also the amount of support that it gets might help with the decision if it makes sense to add this functionality to KIO. Even though it might seem like a simple thing from a user's point of view, implementing this is far from trivial. The protocol that KIO uses to communicate with the kioslave would need to be extended, modifications in the kioslaves and in the core KIO code would be required. And then the applications have to be modified to make use of this changes. This is a considerable effort, which will make future maintenance harder, and it will only work on a subset of the platforms and file systems that KIO is designed to work with. Therefore, I would say that an extremely good reason is required to justify such a request (and finally, someone has to volunteer to write+maintain all that code). But it's not up to me to decide that anyway ;-)
*** Bug 253019 has been marked as a duplicate of this bug. ***
I had overlooked the link, sorry about that. http://forum.kde.org/viewtopic.php?f=83&t=87400
As I said, I'm not responsible for the relevant code at all, but after reading the comments in the forum, I must say that I'm strongly against such a feature. The entry "Clone" (or whatever it's called) will be useful for only a few, but confuse ~99% of all users. Now those who like to create hard links will say "Just add an option for it", but if we add options for every little thing that a few people consider useful (please believe me, there are *lots* of such things), then the maintenance of the application and libraries will quickly turn into a nightmare, because the number of code paths that have to be considered when writing new code and debugging grows exponentially with the number of options. Also handling incoming bug reports becomes much harder - it is very common that a bug can only be reproduced if a particular set of options is enabled. And needless to say, new bugs may appear. Moreover, one of Dolphin's goals is to focus on usability, and therefore, I don't think that adding an option for a feature that is useful to a few users only, who usually know very well how to achieve the desired result using the command line, makes sense.
To Frank Reininghaus: I strongly disagree. Either we want to have rational, full featured operating system of Linux with nice graphic desktop above, or we want to downgrade it (hide/limit/"censor";-) it's features) to support twisted ideas of one big company (the one how's name should never be named ;-) ). I ran here as I am using MMC which can NOT follow symlinks, however works OK with hardlinks. I have to do create kind of shell wizardry myself to be able to properly manage my theme-sorted videotheke links there. Till now I allways thought there are some strong coder's reasons behind not implementing simple "create hardlink" option in the pop-up menu. To hide (complicate access to) some basic features of underlying operating system in desktop file manager because "not to confuse some users" is IMHO not only nonsense. It is total madness, esspecially in the ecosystem like Linux community. At most you could set some "basic/advanced" switch somewhere in Dolphin configuration, which would ensure that the option will not appear for user, who is not actively interrested in the feature...
I also miss this feature a lot. As well as a "Paste as hard link" option when pasting files.
I just came looking for this feature. There are times when you need a hard link and having to do so at the command line is just a pain.
Only hard links work consistently for all users of a shared/network file system (eg. NFS/SMB). Hard links are also needed when a volume is portable. Currently KIO creates full path symlink instead of relative one which is problematic when the volume is mounted on another host. And some OSs (eg. Windows) simply can't process Linux symlink. On the other hand, hard links work reliably for different hosts and different operating systems across the board.
Is there some workaround for the lack of built-in hardlink creation? Maybe something in the "activities" menu? Or something for "Open with..."?
Any news on this now 11 years ticket for a feature request ? I miss this feature weekly and frankly I don't understand the mindset of "let's remove features" in the name of usability. Lacking this feature is a loss of productivity and time wasted and it's been quite a long time now. If you are worried that this feature that people would actually use could be trouble for some other users not knowing better, then this rationale applies to a number of existing features already in dolphin, for example soft links. I happen to be dealing with such 'casual' users on a regular basis as I manage their computer maintenance and provide them support. I can attest that they experienced various level of hardships and difficulties at least a few times with the following dolphin features: - dual panels - tabs - view modes - filter bar - toolbar configuration menu - keyboard shortcuts - keyboard shortcuts menu - hidden files - embedded terminal - the contextual menu - some of the services in the contextual menu - drag and drop This friendly reminder to point out that people will inevitably experience difficulties with even basic features, dumbing down software will not prevent this and is a missed opportunity to help those users learn while pushing away power users. It's really a lose-lose status quo. Imho a proper way to add an advanced feature to a piece of software is the way the old presto-based opera did mouse gestures. On installation this feature is disabled, on first use it would display a message box informing the user that she just used a mouse gesture, asking her if she is familiar with these and wants to enable this feature, to learn about this feature or simply cancel and do nothing. Enabling would remind that you can later disable it from preferences, close the box and enable the feature. Learning would launch a quick tutorial where you learn by doing, following simple visual instructions on screen and ending with offering to enable or cancel Cancel would close the box and do nothing. Back to dolphin and hardlink, it could be possible to have a preferences toggle to switch from a default beginner mode to an expert mode. The expert mode would include a setting to enable linking (both soft and hard) from the drag n drop contextual menu, with an optional tutorial explaining what links are, what the differences between soft and hard are and introduce a couple use cases. I wonder why desktop software design is stuck in a dated mind set that user have to read manuals or assume user already know how to use the software. While other pieces of software such as video games have evolved to include smart tutorials where you learn along by using the software, or have a separate tutorial to learn the controls and the game mechanics by play an introduction level. This would answer both user asking for hard link support in dolphin and devs afraid that including basic unix file management features would confuse and cause trouble to the computer illiterate users. Alternatively if someone has a patch to add this feature to dolphin, or and existing patched version, I would be happy to instantly ditch the vanilla dolphin to switch to the customized version without blinking. In the meantime for those who want an admittedly not so good workaround to this dolphin shortcoming: you can use krusader instead. It includes the ability to hard link files, but instead of being easy to access it's inside a nested submenu of the contextual menu. see screenshot here: https://i.imgur.com/NsqViMw.jpeg
I forgot to ask, is there a bounty somewhere for adding this feature that I can contribute to ?
I think a MR in dolphin implementing it a context menu installed by default but disabled would be welcome. Using KAbstractFileItemActionPlugin similarly to: https://invent.kde.org/graphics/gwenview/-/merge_requests/24/diffs
BTRFS allows "cp --reflink=auto ..." and dolphin transparently uses this functionality. A copy does not take extra space on disc (beyond the directory entry), the space is grabbed when one of the files is updated/written to. It's "Copy on Write" Does this do what you are wanting to do with hardlinks?
No, cp --reflink=auto is not enough. E.g., if I "ln a b" then "du -ch a b" will show 200M, but if I "cp --reflink=auto a b" then "du -ch a b" will show 400M. Same on btrfs and zfs.
(In reply to Marcus Sundman from comment #14) > ... on btrfs ... I think if you do "df" before and after the copy, you'll see that the copy has not actually taken up space. It looks as if "du" is clever enough not to double count space "taken" by hardlinked files but isn't yet up to do the same job for reflinked ones. Maybe "btrfs filesystem du ...". I can see there's a slight difference in behaviour in that after a "ln a b", if you edit either of the files you change them "both". After a "cp reflink=auto a b", if you edit either, you'll get two distinct copies. Question is, assuming you are on BTRFS, might this be good enough?
(In reply to tagwerk19 from comment #15) > (In reply to Marcus Sundman from comment #14) > > ... on btrfs ... > I think if you do "df" before and after the copy, you'll see that the copy > has not actually taken up space. You're right. > Question is, assuming you are on BTRFS, might this be good enough? For btrfs it would be fine (for me, not necessarily for others), but this still doesn't work on zfs or ext4 or any filesystem that does have hardlinks but not CoW-support.
Count me in as another one wanting this in Dolphin. reflinks are a separate matter. I want to be able to create hard links. I'm a heavy command line user, but for this use case, dropping from Dolphin to the console _just_ for creating a hard link is painful. Also, I think Dolphin should support recursively hardlinking directories, just like (GNU) "cp -al" does. Someone in the original forum mentioned that with hard links users can end up confused, and edit a hardlinked file, thinking they are editing a copy. Well, that shows something else that KDE tools like kate, etc. could do -- warn that you're editing a hard linked file (simply checkck the file's link count is > 1). Dolphin itself could have some sort of visual indication for files that are hard linked, like print their icon background in a different color, have a link count column in the details info, or something. Happy KDE user since 1.x...
(In reply to Pedro Alves from comment #17) > Count me in as another one wanting this in Dolphin. reflinks are a separate > matter. I want to be able to create hard links. I'm a heavy command line > user, but for this use case, dropping from Dolphin to the console _just_ for > creating a hard link is painful. Also, I think Dolphin should support > recursively hardlinking directories, just like (GNU) "cp -al" does. > > Someone in the original forum mentioned that with hard links users can end > up confused, and edit a hardlinked file, thinking they are editing a copy. > Well, that shows something else that KDE tools like kate, etc. could do -- > warn that you're editing a hard linked file (simply checkck the file's link > count is > 1). Dolphin itself could have some sort of visual indication for > files that are hard linked, like print their icon background in a different > color, have a link count column in the details info, or something. > > Happy KDE user since 1.x... Given how niche and technical this use case is, I would encourage potential users of this to send an MR. To impl this as a drop option natively: Our copyjob.h would need to support a `hardlink()` function, then dropJob would need to add a new DropAction. This can also be implemented as a kio_dnd plugin https://api.kde.org/frameworks/kio/html/classKIO_1_1DndPopupMenuPlugin.html I would expect a way to disable the drop action.
As a new KDE user I would appreciate this feature a lot. Can't believe that it is still not possible from GUI