Re: [cifs-protocol] cifs client timeouts and hard/soft mounts
On Mon, Dec 06, 2010 at 12:42:55PM -0500, Jeff Layton wrote: On Mon, 06 Dec 2010 11:01:12 -0600 Christopher R. Hertel c...@samba.org wrote: Question (for which I do not have an answer): How much work do you want to do to make their intentionally broken model work? Very little...live by the sword, die by the sword :) I'm not opposed to trying to work around this sort of brokenness, but not at the expense of more conventional configurations. If the proxy keeps responding to echoes regardless of what happens on the server side of its connection then that sounds really broken to me. Does it do nothing to detect whether the server is still around? I don't see a way for us to detect such a broken device if not. There's simply nothing you can do. If a WAN device fakes application level probes (which is what SMBecho is) then you're toast. Just ignore WAN devices. They're supposed to be transparent. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior
On Fri, Dec 03, 2010 at 06:22:01PM -0500, Jeff Layton wrote: Treating different calls differently for timeouts sounds like the road to special-case madness. It seems to me that the best behavior would be to have the client wait for a reply indefinitely if the server is responding to periodic echoes. If that's unacceptable then perhaps a tunable timeout that defaults to something very long (10 minutes or so). +1 from me. hard mounts shouldn't drop connections whilst the server is responding to SMBecho requests. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110112076424325]Problem communicating with SPOOLSS, invalid parameter.
On Tue, Nov 23, 2010 at 12:09:39AM +, Bryan Burgin wrote: Jeremy, I'm researching this for you. I worked with Guenther on similar [MS-RPRN]questions during the Samba IO Lab, along with Nick and Tarun from Microsoft and the Product Group. The two most detailed debugging techniques would be for me to collect ETW traces from you or Time Travel Traces (iDNA Traces). Both would involve receiving logs from you and analyzing them here. As for ETW traces, we would use TraceLog. I'm reviewing the exact GUIDs you need to specify. As for TT Traces, I will also send you the tool to capture the iDNA log. Thanks ! Ping me when you have the information telling me how to do this. After Thanksgiving is fine :-). Can you send me a screen shot showing me the INVALID_PARAMETER error dialog box (0x0057)? Will do - but won't be able to do this until after Thanksgiving now (Monday), sorry. It isn't very helpful, just a standard Error 0x0057 dialog box. Thanks a *lot* for helping with this, I really appreciate it. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:110020359682290] [MS-RPRN] 3.1.4.1.2 Dynamically Typed Query Parameters - Bad variable names
On Wed, Feb 03, 2010 at 08:54:36PM +, David Wooden wrote: Sorry for the re-send, adding our internal tool alias for tracking these issues. -Original Message- From: David Wooden Sent: Wednesday, February 03, 2010 12:52 PM To: Jeremy Allison Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: [REG:110020359682290] [MS-RPRN] 3.1.4.1.2 Dynamically Typed Query Parameters - Bad variable names Hi Jeremy, I have created a case for this issue (case number is 110020359682290) and will be working with you on it. In reading through this section, I believe that you are correct, since cbBuf is not used previously in this section. Since this section is talking about an API pattern rather than a specific API function, it may be that the correct solution is to change... pcbNeeded or pcbData: to pcbNeeded or pcbData or cbBuf: ...because cbBuf is certainly used by some functions in this pattern (as described elsewhere in this document). Please let me know your thoughts. In the meantime, I will dig a little deeper and update you as soon as I have more to add. I'm not sure I follow the API pattern argument. I think each section should be specific to the variable names used above the phrase use. After all, the API pattern leads to the cut-and-paste error I just called out. Might be better to standardize the names across the document in all sections that use them. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [Pfif] CAR: Bad variable names in MS-RPRN : 3.1.4.1.2 Dynamically Typed Query Parameters
Dear Dochelp, In MS-RPRN, section : 3.1.4.1.2 Dynamically Typed Query Parameters. the text reads: 3.1.4.1.2 Dynamically Typed Query Parameters Unless notified otherwise, methods returning one or more dynamically-typed values use a common API pattern, in which the caller passes in the following parameters: BUFFER: A buffer into which the server copies the requested dynamically-typed values. The term BUFFER is used here as a placeholder. Each method section defines which of its parameters is the pointer to the buffer. pType: An optional pointer to a variable that receives a code that indicates the type of data that is stored in the specified value. For a list of possible type values, see section 2.2.3.9. nSize or cbData: The size, in bytes, of the buffer. This value can be larger than the required size for the requested dynamically-typed values. pcbNeeded or pcbData: A pointer to a variable into which the server copies the number of bytes between the start of BUFFER and the last byte written by the server into BUFFER, both inclusive; or the required size of the buffer, in bytes, if the value of cbBuf is smaller than the size of the data to return to the caller. For methods capable of returning more than one dynamically-typed value, the caller also passes in: pcReturned: A pointer to a variable into which the server copies the number of dynamically-typed values that were written to the buffer, if the buffer was large enough to hold them. The individual method sections include the following parameter validation steps by reference: The server MUST verify that the value of cbBuf is not smaller than the number of bytes required to hold the dynamically-typed values to be written to the buffer. If that verification fails, the server MUST write the number of bytes required into the variable that is pointed to by pcbNeeded and return ERROR_MORE_DATA. If the value of cbBuf is not zero, the server MUST verify that a non-NULL pointer to the buffer was passed in. If that verification fails, the server MUST return ERROR_INVALID_USER_BUFFER. I believe the references to the variable name cbBuf in the above are incorrect, and should be replaced with nSize or with cbData. There is no variable name cbBuf defined in this section. It appears to be a cut-and-paste error from 3.1.4.1.7 String Query Parameters, which does define the cbBuf variable name. Please let me know if this is correct. Thanks, Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
On Wed, Nov 25, 2009 at 05:14:26PM +, Bill Wesse wrote: Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. That won't wash I'm afraid. If it's visible on the wire, and it changes the visible behaviour of the file server, then it needs to get documented. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Excel timestamp client side-caching request
On Fri, Aug 21, 2009 at 11:25:57PM +, Hongwei Sun wrote: 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.0 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.0 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.29400 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.0 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. Fantastic analysis ! Thanks. I'll get onto this immediately. Thanks, Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMBTorture tests
On Wed, Apr 15, 2009 at 05:30:54PM -0700, Long Li wrote: Can you tell us how you use SMBTorture BASE, RAW and SMB2 test suites in the Samba project? Is there any documentation that we should use to properly setup the Samba server in the test? Well we mainly use it to determine where we're different from a Windows server, and what we need to keep working on. smbtorture is a protocol tester, not a particular implementation tester. To see how we use it internally, check out the source3/script/tests/ directory for how we use it to check for regressions in the Samba server. There are some extra VFS modules we use there that allow us to pass more of the tests (remember the basic configuration on POSIX won't store NTFS streams, NTFS ACLs or other Windows specific metadata). Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] preliminary UNIX extensions documentation
On Wed, Oct 08, 2008 at 09:33:14AM -0700, James Peach wrote: Hi all, I had some time a couple of months ago, so I knocked up some documentation for the UNIX extensions. Although what follows is in RFC format, I doubt that I will get around to submitting this as a real IETF informational RFC. If someone else wants to do that, I'll happily support that effort. I haven't documented all the UNIX extensions. I have documented all the extensions used by the Mac OS X 10.5 SMB client, however. I'm happy to take patches :) This documentation is licensed under the Common Documentation License, http://www.opensource.apple.com/cdl/. Yay ! James, this is *great* ! I'll try and send patches to add the other stuff. Well done, and thanks a *lot* for taking the time to do this. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Re: [linux-cifs-client] POSIX pathnames and the '\' character.
On Sun, Mar 11, 2007 at 09:49:04AM +0100, Stefan (metze) Metzmacher wrote: Jeremy Allison schrieb: Yes, that's exactly what I'm coding up right now. Wait for the check-in :-). good:-) Actually, this proved much harder than I thought and I junked all my client changes last night. I was able to rescue most of the DFS server fixes though... Then you need 2 code pathes in the server code, and one will never be tested. I think it's not the best design to allow 2 different things in one protocol-field. why not reply and accept a full path with the unix '/' delimiters, when we are in unix mode and a full path with windows '\' delimiters in non-unix mode. I am starting to come to this conclusion myself. It's harder on the clients, as they can be traversing a posix style path to a posix server, and then be given back a referral in Windows path mode, and then have to change on the fly to the relevent delimiter for the referral path only, not the consumed part. This gets so hairy that was what made me junk my client changes above. Currently I've gone back to '\' separators only in DFS paths until I think out the client changes needed. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Re: [linux-cifs-client] POSIX pathnames and the '\' character.
On Sun, Mar 11, 2007 at 12:14:48AM +0100, Stefan (metze) Metzmacher wrote: can't we out that logic into the client, so when the client get the redirect from a server with unix extentions then it converts the redirect url when he talks to a server without unix extentions support. Yes, that's exactly what I'm coding up right now. Wait for the check-in :-). This way the communication over a connection with unix extentions would be consistent. And the client needs to have some logic anyway as \server\share/unix/path isn't valid for connecting to a server without unix extentions. I'm planning to make it \server\share\path/to/unix/file, but the server code will also accept /server/share/path/to/unix/file on the principle of be liberal in what you accept. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
