mount_nullfsのFreeBSDmanページで「getcwd関数が正しく機能する」というステートメントの意味は？
FreeBSDでは、 _man mount_nullfs_ は次のように述べています。
ファイルシステムの仮想コピーとシンボリックリンクの主な違いは、
getcwd(3)関数が正しく機能することです仮想コピー内にあり、他のファイルシステムは元のファイルに影響を与えることなく仮想コピーにマウントできます。バーチャルコピーの異なるデバイス番号がstat(2)によって返されますが、他の点では元のデバイス番号と区別できません。
この段落の完全な意味/意味は何ですか？
ファイルシステムの仮想コピーとシンボリックリンクの主な違いは、仮想コピーでは
getcwd(3)関数が正しく機能することです。 、
シンボリックリンクされたディレクトリでのgetcwdの動作は、かなりよく知られている落とし穴であり、たとえばAdvanced Unix Programmingに記載されています（ this SO質問 引用）：chdirとgetcwdは、シンボリックリンクが含まれている場合は対称ではありません。 chdir を指定のディレクトリに移動し、 getcwd を使用して現在のディレクトリを取得すると、同じ値が返されますが、プロセスがディレクトリを変更する場合はそうではありません。シンボリックリンクを含むパスの使用— getcwdは、すべてのシンボリックリンクを逆参照した後に取得されたパスを返します。これは、シンボリックリンクを含むパスの場合、ディレクトリを親ディレクトリに変更するときに予期しない結果をもたらす可能性があります。 ）と逆参照されたパスには、異なる数のコンポーネントがあります。
また、他のファイルシステムは、元のファイルに影響を与えることなく仮想コピーにマウントできます。
Stéphaneの example を続けると、_/tmp/b_に影響を与えることなく、_/some/dir_のサブディレクトリに別のファイルシステムをマウントできますが、_/tmp/a_のサブディレクトリにファイルシステムをマウントできます。 ）__は、_/some/dir_の下にも表示されます。
バーチャルコピーの別のデバイス番号が
stat(2)によって返されますが、他の点では元のデバイス番号と区別できません。
つまり、コピーまたはその下のファイルでstatを実行すると、元のデバイス番号とは異なるデバイス番号が返されますが、それが唯一の違いです。それとは別に、stat("/tmp/b/c", &buf)とstat("/some/dir/c", &buf)は同じ情報を返します。