Bug #2000


Wrong timestamp on files written over cifs

Added by Vidar Nilsen over 12 years ago. Updated over 2 years ago.

cifs - CIFS server and client
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


We have a ZFS volume shared over CIFS, accessed by clients on windows computers.

When a user unrar a .rar file with winrar, all files will have the current
time as timestamp, not the timestamp from within the archive.
When unzipping the timestamps are correct.

Attached pcap files:
Bge0.rar.pcap is activity when unraring. is activity when unziping.

File from rar archive gets current date as timestamp. File from zip keeps original timestamp.
I used winrar to extract from both rar and zip.

I have contacted winrar about this, and they use the same "logic" for both zip and rar.
The difference is the API-calls for writing files.

Here is the info from winrar support:

Regarding unrar:

If you mean WinRAR, not Unix RAR version, then it uses the standard
CreateFile call to create a file, writes data to file with WriteFile,
sets the file time with SetFileTime, closes the file with
CloseHandle, sets file attributes with SetFileAttributes.
All this API calls are typical.

Regarding unzip:

Now I looked at WinRAR unzip code more carefully. Unlike unrar
code, it opens a file with fopen, writes data, closes the file with
fclose, then re-opens the file with CreateFile, sets the file time
with SetFileTime and closes it with CloseHandle. So unlike unrar
code, it does not write any data to file after CreateFile and before SetFileTime.
But it has its price, time wasted to re-open a file.

On windows servers the timestamps are correct in both cases...


bge0.rar.pcap (64.1 KB) bge0.rar.pcap Network capture while unraring Vidar Nilsen, 2012-01-19 01:40 PM (47.8 KB) Network capture while unzipping Vidar Nilsen, 2012-01-19 01:40 PM

Related issues

Related to illumos gate - Bug #13299: File mtime changes twice, when file is modified using SMB serverClosedGordon Ross

Actions #1

Updated by Vidar Nilsen over 12 years ago

Thanks to WinRAR support, I might have more accurate information on how to reproduce this bug.

From Eugene at winrar support:

I think, they might fail to reproduce the problem based only on this
information. You provided them the quote from my first email on this
issue, where I only started to investigate it and did not really understood what causes it.

It would be more helpful for them to know that SetFileTime does not
work properly if CreateFile is called with GENERIC_READ|GENERIC_WRITE
and then some data was written to file before SetFileTime call.
And SetFileTime works properly if CreateFile was called with
GENERIC_WRITE only or no data was written to file before SetFileTime
call or FlushFileBuffers call or some delay is added before SetFileTime.

It looks like a delayed write operation modifies the file time, but

In unzip code close/reopen works similarly to FlushFileBuffers.

Actions #2

Updated by Gordon Ross over 2 years ago

  • Status changed from New to Closed

This is probably fixed by #13299

Actions #3

Updated by Joshua M. Clulow over 2 years ago

  • Related to Bug #13299: File mtime changes twice, when file is modified using SMB server added

Also available in: Atom PDF