[cifs-protocol] Excel timestamp client side-caching request
hongweis at microsoft.com
Fri Aug 21 17:25:57 MDT 2009
After much of testing and debugging, it seems that we are getting the cause why Windows takes the file offline and the timestamp update only goes to local store. When Windows close one particular handle through which the file had been modified, it queries the timestamps using FIND_FIRST2 on the file after receiving the close response. Those timestamps are then saved in CSC cache. We can see that the LastWriteTime value returned from the create response does not match the value returned from FIND_FRIST2 query. The mismatch of LastWriteTime causes Windows to declare the version conflict between server copy and local cache and thus takes it offline.
Here are the details shown in the traces you sent us..
Opening file, the current time stamp is written to the excel file
Frame 175 10.20.0.111 10.20.0.66 SMB Trans2 Response, FIND_FIRST2, Files: excel test.xls Last Write: Jul 8, 2009 15:10:06.000000000
Frame 185 10.20.0.111 10.20.0.66 SMB NT Create AndX Response, FID: 0x13ff Last Write: Jul 8, 2009 15:10:06.000000000
Frame 214 10.20.0.66 10.20.0.111 SMB Trans2 Request, SET_FILE_INFO, FID: 0x13ff
So far so good..
Closing file, the original time stamp is supposed to be restored to the excel file
Frame 574 10.20.0.111 10.20.0.66 SMB Trans2 Response, FIND_FIRST2, Files: excel test.xls Last Write: Jul 8, 2009 19:36:12.294000000
Frame 587 10.20.0.111 10.20.0.66 SMB NT Create AndX Response, FID: 0x103e Last Write: Jul 8, 2009 19:36:12.000000000
Mismatch of time stamp is detected and remote file is closed and it is going offline. SET_FILEINFO will not sent to the server any update will only goes to local copy.
Frame 588 10.20.0.66 10.20.0.111 SMB Close Request, FID: 0x103e
From all the failed cases I got, I can see that only the millisecond part is different.
You may look at the difference between logics of those two commands regarding LastWriteTime. Please let me know what you think and, if necessary, we can continue working together to debug the problem.
From: Jeremy Allison [mailto:jra at samba.org]
Sent: Tuesday, August 18, 2009 7:30 PM
To: Hongwei Sun
Cc: Jeremy Allison; pfif at tridgell.net; cifs-protocol at samba.org; Edgar Olougouna; Nick Meier
Subject: Re: Excel timestamp client side-caching request
On Sun, Aug 16, 2009 at 05:34:39AM +0000, Hongwei Sun wrote:
> We are still working on identifying the issue. It seems that when Excel tries to send SET_INFO when closing the file, CSC thinks ,for some reason, that the object is in disconnected offline state and any update to the file is just applied to the CSC local cache. That is why the SMB Transact2 request is not really sent over the wire. It looks like that it is timing related as I have much smaller chance to capture the condition if it is running under debugger.
> I will be on vacation next week until Friday. Nick and Edgar will continue working on the issue. If you have any information or requests, please let us know. We will also let you know as soon as we get the root cause on the issue.
Ok, this is very interesting. If there's anything I can do
to help please let me know but it does sound like there's
something the Windows CSC code sees from a Samba server
that it doesn't like and causes it to make the decision
that the drive is offline. You guys are in the best place
to determine what that might be.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cifs-protocol