Not for me, but I can imagine high-performance systems where this might be important. Hard links, being always on the same file system, are always resolved in a single look-up, and never involve network latency (if it's a hardlink on an NFS filesystem, the NFS server would do the resolution, and it would be invisible to the client system). And some of these could be on NFS or other high-latency file systems, and so could result in network traffic to resolve. Hard links also take less time to resolve - symlinks can point to other symlinks that are in symlinked directories. Hard links may take less disk space as they only take up a directory entry, whereas a symlink needs its own inode to store the name it points to. Any symlink to the file in /bin would be broken by this, but a hardlink, being a link directly to the inode for the file, wouldn't care. For example, moving a file from /bin to /usr/bin or to /usr/local/bin. Hard links are useful when the original file is getting moved around. Likewise, If foo is deleted, foo-hard still holds the contents if bar is deleted, bar-soft is just a link to a non-existing file. The contents of the file could not be found because the soft link points to the name, that was changed, and not to the contents. This is not the case for soft links like bar-soft: $ mv bar bar-new Hard links like foo-hard point to the inode, the contents, of the file. Last column: the symbolic link shows the linked-to file via ->Ĭhanging the filename of foo does not affect foo-hard: $ mv foo foo-newĬhanging the contents of foo is reflected in foo-hard: $ printf Dog > foo
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |