Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 02/25/2009 12:03 PM, Ben Eisenbraun wrote: > When I say that hard links can't cross file system boundaries, I mean=20 > the linked files have to be on the same file system on the same partiti= on=20 > on the same physical disk (lvm and RAID notwithstanding). They can't=20 > just be mounted in the same directory tree. > =20 A hard link is an entry in an inode. If you have 2 directories that are=20 on the same file system (meaning the same partition in PC speak) they=20 share the same inode. But, if those same two directories are exported=20 separately, on a system that imports them, they will be different file=20 systems. Example: on the system where the directories reside: /foo/bar and /foo/fubar exists, and in your exports you export /foo/bar=20 and /foo/fubar. On your NFS client you mount host:/foo/bar on /foo/bar and=20 host:/foo/fubar on /foo/fubar. On the NFS client they will NOT be part=20 of the same file system. On Unix systems, /usr/bin/vi is hard linked to /usr/bin/view (and=20 others). On Linux, they are usually symbolic links. If /usr is a mounted = filesystem the hard links will continue to fork because vi and view are=20 both in the /usr file system, even if /usr is imported because the /usr=20 file system will have its own inode table even if it is an NFS file=20 system. I'm trying to keep this reasonably simple. Directories are interesting animals because every subdirectory has a=20 hard link to its parent (.. - / is an exception). When you mkdir, that=20 subdirectory will have a hard link to itself and the parent. An empty=20 directory always has a link count of 2 (the name it was created under=20 and itself (.)). --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |