Project

General

Profile

Bug #2000

Wrong timestamp on files written over cifs

Added by Vidar Nilsen over 8 years ago. Updated over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
cifs - CIFS server and client
Start date:
2012-01-19
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

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.
Bge0.zip.pcap 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...


Files

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

History

#1

Updated by Vidar Nilsen over 8 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
only in GENERIC_READ|GENERIC_WRITE mode.

In unzip code close/reopen works similarly to FlushFileBuffers.

Also available in: Atom PDF