I have a folder which contains a certain number of files which have hard links (in the same folder or somewhere else), and I want to de-hardlink these files, so they become independant, and changes to their contents won't affect any other file (their link count becomes 1).

Below, I give a solution which basically copies each hard link to another location, then move it back in place.

However this method seems rather crude and error-prone, so I'd like to know if there is some command which will de-hardlink a file for me.

Crude answer :

Find files which have hard links (Edit: To also find sockets, etc. that have hardlinks, use find -not -type d -links +1) :

find -type f -links +1

A crude method to de-hardlink a file (copy it to another location, and move it back) :
Edit:As Celada said, it's best to do a cp -p below, to avoid loosing timestamps and permissions.Edit:Create a temporary directory and copy to a file under it, instead of overwriting a temp file, it minimizes the risk to overwrite some data, though the mv command is still risky (thanks @Tobu).

I wouldnt consider that 'crude'. The only way to get that faster is probably doing some trick with the sendfile() system call and unlinking the open source file and rewriting the target in-place. Frankly its not worth the effort though.
–
Matthew IfeMay 6 '12 at 19:10

By 'crude', I mean that, for example, when I ran this command using the cp -i switch, it spat at me a few messages asking if it should override ./fileXXXXXX (the $temp file), even though tmpfile should give unique file names, so there must be some kind of race condition or whatever, and with it the risk to loose some data.
–
Georges DupéronMay 8 '12 at 13:59

1

It's normal that the file exists, you just created it with tempfile (nb: deprecated in favour of mktemp, but that's not what caused your problem).
–
TobuOct 31 '12 at 21:26

@Tobu Thanks, I modified my code to use mktemp -d in order to create a temp dir, in which I copy the file using cp -i, to avoid accidentally overwriting anything. There's still a possible race condition if we start copying the original file, then something removes it and replaces it with some new file, and we mv the copy over that new file, so this script isn't safe when run in, say, a network share, but should be ok for de-hardlinking files on a local disk where we make sure no process is performing modifications while the script works.
–
Georges DupéronNov 1 '12 at 9:42

2 Answers
2

There is room for improvement in your script, for example adding a -p option to the cp command so that permissions and timestamps will be preserved across the unhardlink operation, and you could add some error handling so that the temp file is deleted in case of an error, but the basic idea of your solution is the only one that will work. To unhardlink a file you have to copy it and then move the copy back over the original name. There is no "less crude" solution, and this solution has race conditions in case another process is accessing the file at the same time.

Indeed, I always use cp -a when copying stuff, to preserve everything, recurse and copy symlinks as symlinks. Don't know why I forgot it this time, but after seeing your answer, I understood I had screwed up all my timestamps, and had to (rather painfully) recover them from a backup.
–
Georges DupéronMay 7 '12 at 19:40

I forgot to mention that I didn't have enough disk space to copy everything. Basically, your method is the same as cp -a --no-preserve=links /path/to/folder /path/to/copy && rm -rf /path/to/folder && mv /path/to/copy /path/to/folder, if I'm not mistaken. I guess your method would be more efficient, though, because tar would involve less disk seeks, so less thrashing. One could achieve the same with rsync, with even lower performance than the cp method :).
–
Georges DupéronMay 7 '12 at 19:34

To avoid using much extra disk, it might be possible to run something like tar cvf - --hard-dereference . | tar xf - but there might be a race condition that will cause things to explode. I have not tried it, and I'm sort of disinclined to do so at the moment.
–
cjcMay 8 '12 at 14:35