Jeremy,


    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..



   Office2003-opnclose-samba-bad.cap:



      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.



Thanks!



Hongwei









-----Original Message-----
From: Jeremy Allison [mailto:[email protected]]
Sent: Tuesday, August 18, 2009 7:30 PM
To: Hongwei Sun
Cc: Jeremy Allison; [email protected]; [email protected]; 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:

> Jeremy,

>

>    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.



Thanks,



Jeremy.


_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to