Похоже, это "фиктивная" ситуация, когда у вас есть файл, отображаемый в точке монтирования, и этот файл имеет номер меньше единицы в Inode Links.
Вот структура cifs . cf_nlink
- это количество inode-ссылок, которые имеет конкретный файл.
Этот кусок кода показывает, что он заполнит всю информацию о файлах в 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 отключены, тогда просто замаскируйте его с помощью «я не знаю, сколько у меня n ссылок» CIFS_FATTR_UNKNOWN_NLINK
на стороне клиента Linux CIFS.
Однако может случиться так, что у файла есть cf_nlink , и это не файл, в котором выполняется действие удаления (
! Info-> DeletePending
), а также недоступны расширения Unix ( tcon-> unix_ext
), чем это странно. Файл без жестких ссылок, который не удаляется, вы получите сообщение: CIFS VFS: фиктивное значение nlink файла 0
Я полностью понимаю ситуацию, но не могу предоставить вам решение. . Возможно принудительное использование расширений unix, поскольку у вас есть unix-подобные на клиенте и на сервере, может замаскировать проблему.