Raspbianを実行しているRaspberryPiでSMB共有からのファイルを使用しています。これらのファイルにアクセスするたびに、syslogに次のメッセージが表示されます。
CIFS VFS: bogus file nlink value 0
それは実際にはどういう意味ですか、そしてどうすればそれを取り除くことができますか?
SMBサーバーはApple TimeCapsuleです。
マウントポイントにファイルが表示されていて、このファイルの番号がiノードリンクに1つ未満の「偽の」状況のようです。
ここに、 cifs構造 があります。 cf_nlink
は、特定のファイルが持つiノードリンクの数です。
この部分 コードは、ファイルに関するすべての情報をcifsに入力することを示しています
if (symlink) {
fattr->cf_mode = S_IFLNK;
fattr->cf_dtype = DT_LNK;
} else if (fattr->cf_cifsattrs & ATTR_DIRECTORY) {
fattr->cf_mode = S_IFDIR | cifs_sb->mnt_dir_mode;
fattr->cf_dtype = DT_DIR;
/*
* Server can return wrong NumberOfLinks value for directories
* when Unix extensions are disabled - fake it.
*/
if (!tcon->unix_ext)
fattr->cf_flags |= CIFS_FATTR_UNKNOWN_NLINK;
} else {
fattr->cf_mode = S_IFREG | cifs_sb->mnt_file_mode;
fattr->cf_dtype = DT_REG;
/* clear write bits if ATTR_READONLY is set */
if (fattr->cf_cifsattrs & ATTR_READONLY)
fattr->cf_mode &= ~(S_IWUGO);
/*
* Don't accept zero nlink from non-unix servers unless
* delete is pending. Instead mark it as unknown.
*/
if ((fattr->cf_nlink < 1) && !tcon->unix_ext &&
!info->DeletePending) {
cifs_dbg(1, "bogus file nlink value %u\n",
fattr->cf_nlink);
fattr->cf_flags |= CIFS_FATTR_UNKNOWN_NLINK;
}
}
手段:シンボリックリンクの場合は、属性を設定するだけです。 Unix拡張機能が無効になっているときにサーバーが間違った数のリンクを返す可能性があるディレクトリの場合は、LinuxCIFSのクライアント側で「nlinkの数がわからない」CIFS_FATTR_UNKNOWN_NLINK
でマスクするだけです。 。
ただし、ファイルにcf_nlink < 1
があり、削除アクションが発生しているファイルではなく(!info->DeletePending
)、Unix拡張機能が利用できない(tcon->unix_ext
)場合もあります。ハードリンクがなく、削除されていないファイルには、次のメッセージが表示されます:CIFS VFS: bogus file nlink value 0
私は状況を完全に理解していますが、これに対する修正を提供することはできません。 たぶんクライアントにunixライクがあるので、unix拡張を強制サーバーサイトで問題を隠すことができます。