Есть сетевой диск на Linux, есть Windows 10 которая подключается к нему по протоколу SMB2 и сделан маппинг диска на букву Z.
Windows 10 некорректно возвращает приложениям информацию о дате и атрибутах (т.е. атрибут файл или директория).
Я написан простую программу на с которая показывает время каталога и файла (вложенный в этот каталог) (с диска Z) через CreateFileA + GetFileTime + CloseHandle.
И одновременно смотрел трафик через сеть на сервер Linux.
Заметил, что когда есть запросы к Linux — то всё в порядке.
Но иногда запросов нет (видимо Windows берёт из своего кеша данные) то тогда LastWriteTime показывает некорректно, т.е. берёт его от другого элемента.
Если обращаться к файлам через \\192.168.1.10\ результат такой же.
GetFileInformationByHandle() так же как и GetFileTime() возвращает иногда неверную дату и атрибуты. Так же заметил, что nFileIndex одинаковый у файла и каталога. Так же быть не должно ?

Что делать ? Куда смотреть ?

Здравствуйте, maks1180, Вы писали:

M>Что делать ? Куда смотреть ?

Попробуй поменять в реестре (сохранить в .reg, или руками), перезагрузится и проверить:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters]
"DirectoryCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"FileInfoCacheLifetime"=dword:00000000

Здравствуйте, maks1180, Вы писали:

M>Что делать ? Куда смотреть ?

Код показывай, без этого непонятно, куда смотреть, особенно после замечания про nFileIndex.

S>Код показывай, без этого непонятно, куда смотреть, особенно после замечания про nFileIndex.

void PrintTime(const FILETIME *lpFileTime, LPCSTR name)
{
SYSTEMTIME t = {0};
if (::FileTimeToSystemTime(lpFileTime, &t)==0) { printf("ERROR %u of FileTimeToSystemTime() \n", (int)::GetLastError()); }
printf("%s = %4u-%02u-%02u %02u:%02u:%02u.%03u \n", name, (int)t.wYear, (int)t.wMonth, (int)t.wDay, (int)t.wHour, (int)t.wMinute, (int)t.wSecond, (int)t.wMilliseconds);
}

void PrintFileTime(LPCSTR name)
{
HANDLE h = ::CreateFileA(name, 0, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_BACKUP_SEMANTICS, NULL);
if (h==INVALID_HANDLE_VALUE) {
printf("ERROR %u open file %s \n", (int)::GetLastError(), name);
return;
}

printf("%s \n", name);

FILETIME t1 = {0}, t2, t3;
BY_HANDLE_FILE_INFORMATION info = {0};

if (::GetFileTime(h, &t1, &t2, &t3)==0) {
printf("ERROR %u of GetFileTime() \n", (int)::GetLastError());
}

if (::GetFileInformationByHandle(h, &info)==0) {
printf("ERROR %u of GetFileInformationByHandle() \n", (int)::GetLastError());
}
else {
printf("attr=%X, size=%u %u \n", (int)info.dwFileAttributes, (int)info.nFileSizeLow, (int)info.nFileSizeHigh);
printf("index=%X %X = %u %u \n", (int)info.nFileIndexLow, (int)info.nFileIndexHigh, (int)info.nFileIndexLow, (int)info.nFileIndexHigh);
PrintTime(&info.ftLastAccessTime, "LastAccessTime");
PrintTime(&t2, "LastAccessTime");
PrintTime(&info.ftLastWriteTime, "LastWriteTime ");
PrintTime(&t3, "LastWriteTime ");
PrintTime(&info.ftCreationTime, "CreationTime ");
PrintTime(&t1, "CreationTime ");

}

printf("\n");

::CloseHandle(h);
}

#define NETPATH "Z:\\T_8T\\xxx\\xxx\\Tester\\"

int main()
{
PrintFileTime(NETPATH"Debug");
PrintFileTime(NETPATH"Debug\\01.txt");
return 1;
}

M>Что делать ? Куда смотреть ?
Разоборался, проблема из-за того что Linux передаёт одинаковый FileId (для файла и каталога), из-за этого кэш Windows начинает работать не правильно.

Далее разбирался с Linux, и увидел что он хранит что-то а user_attr файлах и каталогов, а именно:
user.DOSATTRIB=0sAAAEAAQAAABRAAAAIAAAAFqdKKmTBdgDQp0oqZMF2AE=
тут информации явно больше, чем атрибуты файла. Подозреваю что тут храниться FileId который передаётся клиенту.
Кто-нибудь знает что здесь храниться ?

Кажется ситуация прояснилась: Windows при копировании на сетевой диск передавала почему-то одинаковый FileId, а потом получив одинаковый FileId, кэш переставало корректно работать.
Вот такое интересное раследования получилось на несколько дней

M>Кажется ситуация прояснилась: Windows при копировании на сетевой диск передавала почему-то одинаковый FileId, а потом получив одинаковый FileId, кэш переставало корректно работать.
M>Вот такое интересное раследования получилось на несколько дней
FielID это сущность привязанная к файловой системе — уникальный идентификатор файла на ней. Непонятно, зачем винда его вообще передает при создании файла (а точно передает? может там чето напутали в линуксе?). По идее линуксу не надо специально хранить никакого FileID, а надо лишь отдавать свой inode number этого файла.

O>FielID это сущность привязанная к файловой системе — уникальный идентификатор файла на ней. Непонятно, зачем винда его вообще передает при создании файла (а точно передает? может там чето напутали в линуксе?). По идее линуксу не надо специально хранить никакого FileID, а надо лишь отдавать свой inode number этого файла.
Да, линукс отдаёт inode number в качестве FileID, если у файла нет user_attr, но если есть user_attr, то отдаёт что-то другое.

O>>FielID это сущность привязанная к файловой системе — уникальный идентификатор файла на ней. Непонятно, зачем винда его вообще передает при создании файла (а точно передает? может там чето напутали в линуксе?). По идее линуксу не надо специально хранить никакого FileID, а надо лишь отдавать свой inode number этого файла.
M>Да, линукс отдаёт inode number в качестве FileID, если у файла нет user_attr, но если есть user_attr, то отдаёт что-то другое.
Уверен что это косяк линукса, FileID не изменяемая штука — его нельзя 'задать' извне, а значит и в user_attr хранить не надо.
Оно? https://bugzilla.samba.org/show_bug.cgi?id=14121

O>Уверен что это косяк линукса, FileID не изменяемая штука — его нельзя 'задать' извне, а значит и в user_attr хранить не надо.
O>Оно? https://bugzilla.samba.org/show_bug.cgi?id=14121

По описанию похоже, только у меня версия 4.13.14, должно быть исправлено уже.

O>>Уверен что это косяк линукса, FileID не изменяемая штука — его нельзя 'задать' извне, а значит и в user_attr хранить не надо.
O>>Оно? https://bugzilla.samba.org/show_bug.cgi?id=14121
M>По описанию похоже, только у меня версия 4.13.14, должно быть исправлено уже.
Стоит проверить применен ли фикс, так как древо линуксов ветвисто и непознаваемо.
В целом, я нашел зачем там этот file_id вычисляется вместо отдачи айнода — это такой костыль для кластеров, причем с настраиваемым поведением, вот тут вот описано — https://www.samba.org/samba/docs/current/man-html/vfs_fileid.8.html