Good morning Tim - development has responded to the TDI - thank you very much
for finding and reporting this - as well as for the opportunity for us to
improve our implementation and documentation! Please let me know if this
answers your question satisfactorily; if so, I will consider your
Bill, Thank you for diving into this issue and bringing clarity to how
others should be implementing this. I sincerely appreciate your
dilligence!
-Tim
On Dec 18, 2009, at 5:38 AM, Bill Wesse wrote:
Good morning Tim - development has responded to the TDI - thank you
very much for
My pleasure - this was - and is - a very interesting topic!
By the way, I will be continuing my study of SMB_INFO_PASSTHROUGH and the
Nt*Info calls. I expect to post a blog entry on the 'Microsoft Open
Specification Support Team Blog' (http://blogs.msdn.com/OpenSpecification/)
sometime in
Good day Tim. I have just filed a Technical Documentation Issue (TDI) against
the share mode issue requesting document update / guidance concerning
SMB_INFO_PASSTHROUGH.
My examination of our implementation indicates this situation should exist for
all SET_PATH_INFORMATION information levels
Thank you for the update! So if I understand what you're saying, it
is possible for a windows app to cause the the smb client to send the
passthrough levels over the wire using NtQueryInformationFile?
-Tim
On Dec 16, 2009, at 10:55 AM, Bill Wesse wrote:
Good day Tim. I have just filed a
Indeed it is possible; NtQueryInformationFile with standard information levels
does translate into passthrough levels on the wire (for SMB).
But, as I mentioned, I am still working on the test code, and haven't invoked
NtSetInformationFile or other functions yet; I am iterating on test cases to
Good morning Tim - here is a summary of my progress to-date concerning your
questions.
==
Question:
The specific case I'm interested in is the following:
1. Client1 does a CreateFileAndX() on a non-existant file with a
-Original Message-
From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-
boun...@cifs.org] On Behalf Of Bill Wesse
Sent: Tuesday, December 08, 2009 6:08 AM
To: Tim Prouty
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo
Thank you for your diligence on this Bill and the answers you have
provided. I have some responses inline below.
On Dec 8, 2009, at 6:07 AM, Bill Wesse wrote:
Is #3 actually correct behavior that other servers should implement?
If so, can the cases where share modes are not enforced be
On Dec 3, 2009, at 10:04 AM, Bill Wesse wrote:
I have retested without SmbSecuritySignatures - results were the same.
I will hold off on the WordCount/ByteCount truncation against the
Dos INVALID_LEVEL error problem
(trans2setpathinfo_against_win7_2.pcap) for the time being, and work
on
Thanks for the update - my Win7 client is also Ultimate, with no updates.
On another note, I just finished an initial debug on srv.sys; I have
considerable analysis to do on the results, specifically tracking down the
handles (just to make sure - even though there are no handle failures in
I have retested without SmbSecuritySignatures - results were the same.
I will hold off on the WordCount/ByteCount truncation against the Dos
INVALID_LEVEL error problem (trans2setpathinfo_against_win7_2.pcap) for the
time being, and work on the sharing issue (I expect to be soaking in code for
On Nov 30, 2009, at 6:06 PM, Tim Prouty wrote:
Hi Bill,
I have done some more investigation on this issue, particularly around
doing a Trans2SetPathInfo() with the documented
FileEndOfFileInformation (0x104) level. It returns what I would
expect to be an acceptable error for an unknown info
1. Packet 40 appears to have the WordCount and ByteCount truncated,
making the packet smaller than normal minimum size of 35? Is this
intended behavior that other servers should implement?
This is a surprise - I have never seen an SMB error packet without WordCount
and ByteCount.
I will
14 matches
Mail list logo
