What is the Unix command to create a hard link to a directory in OS X?

Question

How to create a hard link (as opposed to a symbolic link or Mac OS alias) in OS X that points to a directory? I already know the "ln target destination" command, but this only works when the target is a file. I know that Mac OS, unlike other Unix environments, allows you to set the binding to folders (for example, it is used for Time Machine), but I do not know how to do it myself.

Answer 1

You cannot do this directly in BASH. However ... I found an article here that discusses how to do this indirectly: http://www.mactech.com/articles/mactech/Vol.23/23.11/ExploringLeopardwithDTrace/index.html , compiling a simple little C program:

#include <unistd.h> #include <stdio.h> int main(int argc, char *argv[]) { if (argc != 3) return 1; int ret = link(argv[1], argv[2]); if (ret != 0) perror("link"); return ret; } 

... and build in Terminal.app with:

 $ gcc -o hlink hlink.c -Wall 

Answer 2

I agree that hard folders / directories can be problematic if not careful, but they have a very definite advantage - Time Machine is a great example. Without them, this simply would not be practical, since duplicating redundant versions of files would very quickly consume even the largest of the disks.

Snow Leopard can create hard links to directories if you follow the six rules of Amit Singh:

• The file system must be written to the HFS + log.
• The parent directories of the source and destination must be different.
• The source parent must not be the root directory.
• The destination should not be in the root directory.
• The destination should not be a descendant of the source.
• The recipient should not have ancestors who have a hard link directory.

So it’s not entirely true that Snow Leopard has lost the ability to create hard links to folders.

I just confirmed that / unlink works on Snow Leopard - as long as you follow the six rules. I just tried it and it works fine on my Snow Leopard 10.6.6 system - I tried it on the boot disk and on a separate external USB port, and in both cases it worked fine.

Here is the program "hunlink.c":

 #include <stdio.h> #include <unistd.h> int main(int argc, char *argv[]) { if (argc != 2) return 1; int ret = unlink(argv[1]); if (ret != 0) perror("unlink"); return ret; } gcc -o hunlink hunlink.c 

So, be careful if you try - remember to follow the rules and use hlink to create these hard links and use hunlink to remove the hard link after that. And don't forget to document what you did for a later one or for someone who might need to know this.

Another “bug” I just found out about these “hard links” to folders. When you create them, a lot really happens that happens behind the curtain of Mac OS X. One really important problem is that the folder you create the link to is really moved to a supermagic super-hidden folder called /.HFS+ Private Directory Data% 000d / dir_xxx, where xxx is the inode number in "source_folder" - remember that the command format

 hlink source_folder target_folder 

Therefore, because of this, you should be careful not to open files in the "source_folder", because if you do, they just moved to the supermagic folder, and you will probably have a problem if you try to save any changes to those files that were opened in the "source folder". This happened to me a couple of times, until it began to ask me what was going on, and the solution was quite simple. I noticed that you can no longer execute the “ls -la” command without getting funny errors for all the folders / directories that were in the original “source folder”, but you could make the “ls” command and everything looked good.

If you run “Check Disk” in the “Disk Utility” program, you will notice that it probably complains and gives “The bitmap of the volume needs a little repair for orphan blocks”, which happened with the creation of the super-magic folder and movement " source_folder "to her.

If you are faced with this “lost blocks” situation, first save the modified files to a different temporary location, rather than to the volume containing the source_folder tree, and then use the Disk Utility to unmount and reinstall the volume that contains the source_folder or just reboots the computer. Then copy the files that you saved to temporary places to the original location, and you should be back in business. This is what worked for me, so it cannot guarantee that it will work for you either. Therefore, it would be nice to try this on the volume on which you have a good backup just in case.

It seems very strange that all this overhead occurs only for the simple task of creating a hard link to a folder. Does anyone know why Mac OS X is working hard to create this hard link in folders? Is this due to the fact that this is a “journaled” file system?

I discovered information about a supermagical, super-hidden place by reading Amit Singh's explanation of his "hfsdebug" utility. If you want more information on your website at Amit Singh hfsdebug utility . This software is very interesting and will tell you a lot of details about HFS + file systems. It is free and I recommend that you download it and try it. It is no longer supported, but it still works on both Snow Leopard and Leopard - mainly on any supported HFS + system. You cannot harm it, as it is a read-only tool, so it’s useful to use some details of the file system.

Another problem about these “hard links to folders” is that after creating one and super-magical top-secret hidden folder it is created, it is there forever. Even if you disconnected the folder that created it first, this magic folder remains. Not sure why, but it is definitely. You can use "hfsdebug" to find out if you want to try it. You can also use "hfsdebug" to find out how many of these "folder hard links" exist on disk. See the Amit article in the hfsdebug utility for more information.

He also has another new utility that is supported but worth it. It is called fileXray and costs $ 79 for one person on any number of computers in the same house for a personal license for a non-business type. It contains an extensive 173-page user manual that can be downloaded to see what it can do before purchase. Unfortunately, there is no trial version, so read the manual and go to the website for more information to see if it can help you in traffic. Find out all the details about this on your website - see the fileXray website for more information.

There are several issues you should be aware of when using these hard links to folders. If the volume on which they are created is mounted on a remote client, significant problems can occur, depending on how they are mounted. If you use AFP to connect the volume to a remote client, big problems arise, since any folder that currently has a hard link to it or has ever had it, but later deleted, cannot be used like all lower-level folders (but not files) will be inaccessible from the Finder or Terminal window. If you try to run the simple command "ls -lR", it will fail and give you the error messages "ls: xxx: No such file or directory" for all lower level folders. If you use the Finder window to move through the directory tree of the remote volume, the folders located in the folder with or having a hard link will simply disappear without any error when you first click on the folder name.

These problems do not appear (except for the error message) if you use NFS to connect a remote client (and suppose you have an NFS server on the system with the volume as the local HFS + file system). Details on how to use NFS to mount volumes are not provided here. I used a good program from Dr. Marcel Brezink called "NFS Manager" to help with mounting NFS on the server and client. You can get it from your website - just search for “Bresink NFS Manager” in your favorite search engine, but it does have a free trial so you can try before buying. This is not such a big deal if you want to learn how to do NFS mounts, but NFS Manager simplifies the configuration and adjusts all the settings to optimize it. It has a few neat Mac OS X utilities that are very reasonably priced - one called “Hardware Monitor”, which allows you to track and graphically display all kinds of things, such as power consumption, CPU temperature, fan speeds and many other variables for both local and remote Mac systems for extended periods of time (from a few minutes to a few days). Definitely worth checking to see if you have a handy utility.

One thing I noticed is that NFS file transfers were about 20% slower than using AFP, but your “mileage may vary”, so no guarantees exist anyway, but I would prefer something that works even if I have to pay 20% of the performance, compared to the fact that nothing works at all.

Apple is aware of issues with hard links and remote AFP file systems, and they refer to it as a “restriction restriction” for the AFP client. I prefer to call it what it really seems to me - BUG !!! I can only hope that the next version of Mac OS X will fix the problem, since I really like being able to use hard-link to folders when that makes sense.

These notes are my personal opinion, and I do not make any guarantees regarding their correctness, so use them at your own risk. Have a good backup before playing with these “hard links to folders” in case something unexpected happens. But I hope you have fun if you decide to take a little look at this interesting aspect of Mac OS X.

Answer 3

bad manners. At 10.5, it tells you on the ln man page:

  -d, -F, --directory allow the superuser to attempt to hard link directories (note: will probably fail due to system restrictions, even for the superuser) 

So yes:

  sudo ln -d existing_dir new_hard_link 

Give the password and you have not done it yet . You have not documented this, have you? You must document hard-coded directories; even if it is one user machine.

Removing is a different story: if you do this in the usual way of deleting directories, you will delete the contents. Thus, you must “unlink” the directory:

  unlink new_hard_link 

There. I hope you do not destroy your file system!

Answer 4

Cross wiring is a great tool that gently solves the problem Sam originally posted:

---

To install Hardlink, make sure you install homebrew , then run:

 brew install hardlink-osx 

After installation, create a hard link:

 hln [source] [destination] 

I also noticed that the unlink command does not work on the snow leopard, so I added the ability to disconnect:

 hln -u destination 

---

The code is available on Github for those interested: https://github.com/selkhateeb/hardlink

Answer 5

Yes, it is supported by the kernel and the file system, but since it is not intended for general use, it does not appear in the shell.

You could probably decide which Time Machine APIs to use and wrap them in a command-line tool, but it would be better to use a hint and clearly control it.

Answer 6

In my case, I found out that I can not follow symbolic links from a Windows virtual machine. (I wanted to check out some HTML pages in Internet Explorer). And my directory structure contained symbolic links to folders with CSS and images.

My workaround for solving the problem was a different approach than the other implied. I used rsync to create a copy of the folder. Rsync can resolve symbolic links and copy related files.

This solved my problem without using hard links to directories. And this is actually a simple solution if you just work with a small set of files.

 rsync -av --copy-dirlinks --delete ../htmlguide ~/src/ 

Answer 7

The OSX ln version cannot do this, but as mentioned in another rich answer, this is possible with the GNU ln version which is available in homebrew as gln as part of coreutils . man gln lists the -d with the OSX warning specified in rich . In other words, it does not work in all cases. What exactly determines whether it works or not seems to be documented nowhere.

As a prerequisite, install coreutils :

  brew install coreutils 

Now you can do:

  sudo gln -d /original_folder /mirror_folder 

IMPORTANT To remove a hard link, you must use gunlink :

  sudo gunlink /mirror_folder 

Using rm or Finder will also delete the original folder.

FYI: coreutils homebrew formula provides GNU-compatible versions of common unix tools. Use brew list coreutils to view a complete list.

Answer 8

The short answer is: you cannot. :) (except, perhaps, root, when it would be more accurate to say that you should not.)

Unixes only allow a certain number of directory links - ".." of all its children and ".". from within yourself. Everything else is potentially a recipe for a very confusing directory tree. This / was apparently Ken Thompson's design decision.

(Having said that, obviously, Apple Time Machine does it :))

Answer 9

In an article related to this article, you will get this error if you try to create a hard link in the same directory as the original. You have to create it somewhere else.

Answer 10

Another solution is to use bindfs https://code.google.com/p/bindfs/ , which is installed through the port:

 sudo port install bindfs sudo bindfs ~/source_dir ~/target_dir 

Answer 11

This can also be done with embedded Perl (from the terminal) without compiling anything. My specific use case is for Google Drive (which does not support symbolic links), so the examples below reflect the use case.

To link the Docs folder to Google Drive so that it syncs:

 perl -e 'link "/Users/me/Documents", "/Users/me/Google Drive/Documents"' 

To remove a link to the Docs folder from Google Drive:

 sudo perl -U -e 'unlink "/Users/me/Google Drive/Documents"' 

You need “root” to disconnect (see “Disable” perldoc).

Answer 12

if there is no subfolder you can try

ln folder_path / * . * target_folder

it worked for me on OSX 10.9

Answer 13

On Linux, you can use binding binding to simulate hard links. Not sure about OSX

 sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory sudo umount /else/dummy_but_existing_directory