
私はディレクトリのハードリンクが危険な理由(ループ、親ディレクトリリンクによるrmdirの問題)を理解し、そのトピックに関する他の質問を読んだ。だから私はと以外のディレクトリへのハードリンクが使用されていないと.
仮定します..
。しかし、CentOS 5と6では、次のことがわかります。
# ls -id /etc/init.d/
459259 /etc/init.d/
# ls -id /etc/rc.d/init.d/
459259 /etc/rc.d/init.d/
# ls -id /etc/init.d/../
458798 /etc/init.d/../
# ls -id /etc/rc.d/
458798 /etc/rc.d/
# ls -id /etc/
425985 /etc/
つまり、同じinodeを指し、同じinodeを指さないディレクトリへの2つの異なるパスが/etc/init.d/
実際にハードリンクディレクトリの場合/etc/rc.d/
ですか?/etc/
そうでなければ何ですか?それでは、Red Hatがこれを行う理由は何ですか?
編集:愚かな質問をして申し訳ありません。シンボリックリンクであることがわかります。今日はコーヒーが足りないようです。
答え1
ハードリンクではなくソフトリンクです。シンボリックリンクは他のファイルを指します。シンボリックリンクを開くと、そのリンクが指すファイルが開きます。 rm を使用してシンボリックリンクを削除すると、シンボリックリンク自体は削除されますが、実際のファイルは削除されません。
これは許可の開始時に文字lで示される。
lrwxrwxrwx. 1 root root 11 Aug 10 2016 init.d -> rc.d/init.d
さらに、rc0.dからrc6.dまでのすべてのファイルは、rc.d/rc0.dへのシンボリックリンクです。
答え2
RHEL、Fedora、CentOSでは、/etc/init.d
例シンボリックリンク到着する/etc/rc.d/init.d
。ハードリンクは含まれません。
Red Hatが必要な場合でも、使用されるファイルシステムでは不可能です。
答え3
この投稿は少し古いですが、OPが見ている動作はまだ説明されていないようです。他の人が言ったように、/etc/init.d
はい/etc/rc.d/init.d
。欠けている部分は、上記の2つのパスが同じinodeを返す理由です。これは、末尾のスラッシュを使用するためです。パスがスラッシュで終わると、ディレクトリがターゲットディレクトリであることをカーネルやその他のツールに通知します。意図したターゲットが実際に存在しないディレクトリの場合、mv / cpコマンドがファイル名を変更しないように保護します。また、lsが使用するlstat(2)システムコールがシンボリックリンクを逆参照し、それが指すディレクトリを返すようにします(既存のディレクトリを指さないとエラーが発生します)。違いを確認するには、次の例を試してください。
$ ls -id .
927578 .
$ ls -id ./parent
927641 ./parent
$ ls -id ./parent/
927641 ./parent/
$ ls -id ./parent/child
927643 ./parent/child
$ ls -id ./parent/child/
927643 ./parent/child/
$ ls -id ./child
927645 ./child
$ ls -id ./child/
927643 ./child/
$ ls -idL ./child
927643 ./child
$ ls -id ./child/..
927641 ./child/..
$ ls -id ./child/../..
927578 ./child/../..
末尾のスラッシュの存在はシンボリックリンクの場合にのみ重要ですが、リンクのinodeは隠されていることがわかります。また、lsの-Lオプションはすべてのファイルタイプに対して機能しますが、同様の操作を実行します。