Re: SMB URL
On Tue, 25 Mar 2003 21:39:26 +0100 Stephan Kulow [EMAIL PROTECTED] wrote: Hi! I looked into the URL handling libsmbclient is doing and it's lacking quite some of the stuff that the DRAFT specifies (and some of the stuff that generally are required for URIs). Is someone working on that? I'm currently preparing some patches, but hate C programming enough to dump it for some other solution :) Greetings, Stephan Please look at the jCIFS mailing list for discussions in February about the SMB URL. There was an interesting discussion about Unicode hanlding. The problem of course is that URLs require characters outside of ASCII to be escaped with %HH hex escapes. This is of course not very reasonable with SMB URLs so hex escaping is not required. In practice this should not be a problem because these URLs are not submitted as parameters to text based RPCs like HTTP GET requests. We did reach an important conclusion that would be influential to anyone writing an SMB URL parser. That is, even though SMB URLs do not require Unicode characters be escaped (for practical reasons) they should be able to decode escaped Unicode characters. This begs the question; how do you escape Unicode characters? The prevailing answer appears to be specified in the W3C IRI documents which suggest each escape should be treated as a byte in a UTF-8 multibyte sequence. Otherwise, the SMB URL is reasonably well defined. Unicode handling was the only remaining issue I believe. The jCIFS client implements all of this functionality minus the decoding of escaped UTF-8 sequences. Please join the jCIFS mailing list if you have specific questions. We have had many interesting discussions there about the SMB URL, we have implemented it completely, and there are three people who understand it quite well. Chris and Eric have the brains. Me type. I'm not familiar with the state of the libsmbclient SMB URL handling. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: Getting notification upon loss of connection (libsmbclient)
On Wed, 12 Mar 2003 16:07:43 -0500 [EMAIL PROTECTED] wrote: I have not been able to find the block of code that will be called if an open connection receives an indication that the peer has gone away (i.e. shutdown, crashed, cable cut, etc.). More specifically, if I have an open, established connection by having previously done: cli_connect() cli_session_request() cli_session_setup() cli_send_tconX() and now the remote server goes away (let's say it crashed suddenly), how can I find this out? I'm not familiar with libsmbclient but I believe you will just have to try to perform some operation and catch the error code. If the error codes are consistent (e.g. EIO) you can trap and reinitialize the request in a way that would be transparent to the user. Otherwise the library would need to send NBT keepalives or use an out of band heartbeat of some kind. Smbclient sort of does this by repeatedly sending an SMB_COM_CHECK_DIRECTORY every 3 seconds. That probably serves a similar purpose. But this is a TCP thing, not a libsmbclient thing. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: [PATCH] file change notification
On Mon, 3 Mar 2003 22:03:02 +0100 [EMAIL PROTECTED] (Juergen Hasch) wrote: Hi, attached is a modified version of Hal's file change notification patch. It's against Samba HEAD and works for me. Changes: - use push_ucs2() to send unicode file names - make some functions static (make proto works now) - limit maximum number of directory entries stored in the TDB to 2000, so large directories won't create monster TDBs. - the maximum reply packet size is limited to 64K. I guess this should never be a problem :-) What ist the maximum allowed size of a NT_TRANS packet anyway ? Each packet can be no more than 64K but an SMB_COM_NT_TRANSACTION may be multiple PDUs for what might amount to an endless stream (i.e. named pipe). The MaxParameterCount field in the request indicates how large the response can be. From the one pcap I have of W2K--W2K it's 4096. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: SMB_QUERY_FILE_ALL_INFO not correct in SNIA spec?
On Tue, 18 Feb 2003 22:30:44 -0800 (PST) Richard Sharpe [EMAIL PROTECTED] wrote: On Tue, 18 Feb 2003, Joey Collins wrote: The SNIA definition of the data required for SMB_QUERY_FILE_ALL_INFO does not appear to be correct. Furthermore, Ethereal's interpretation does not seem right, either. That is quite possible. We often rely on the SNIA doc, and then change things if they don't look quite right. I recall messing with one of the QUERY_FILE info levels because the attributes displayed were clearly wrong. When I tried this it caused delayed blue screen in NT 4 w/ Unicode. I remember it well because I was running the client from Linux via exceed on the NT machine I was killing and it took me a couple times to realize what was happening. More evidence that if you see NT avoids an otherwise useful command (e.g. SMB_COM_COPY) it probably doesn't work. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: interesting fact about StrCaseCmp
On Tue, 18 Feb 2003 11:35:32 +1100
Martin Pool [EMAIL PROTECTED] wrote:
On 18 Feb 2003, Andrew Bartlett [EMAIL PROTECTED] wrote:
Possibly only for long strings? But then that is probably
micro-optimization.
If we really cared about optimizing this function, then we would
compare character-by-character rather than converting both strings to
uppercase first. This is a bit hard for some wierd encodings I know,
but it ought to be possible to do it in charcnv.c.
Actually you got me thinking and it's not all that hard. In fact I think
there are a lot of good optamizations you can make in this function. For
example you only have to convert to wide characters if *both* characters
are multibyte sequences. If only one has the high bit on they cannot
possibly match even caseless so *str1 != *str2 clause will return.
Here's some rough code. I didn't even try to compile this.
int
utf8casecmp(const char *str1, size_t sn1, const char *str2, size_t sn2)
{
size_t n1, n2;
wchar_t ucs1, ucs2;
mbstate_t ps1, ps2;
unsigned char uc1, uc2;
memset(ps1, 0, sizeof(ps1));
memset(ps2, 0, sizeof(ps2));
while (sn1 0 sn2 0) {
if ((*str1 0x80) (*str2 0x80)) { /* both multibyte */
if ((n1 = mbrtowc(ucs1, str1, sn, ps1)) 0 ||
(n2 = mbrtowc(ucs2, str2, sn, ps2)) 0) {
perror(mbrtowc);
return -1;
}
if (ucs1 != ucs2
(ucs1 = towupper(ucs1)) != (ucs2 = towupper(ucs2))) {
return ucs1 ucs2 ? -1 : 1;
}
sn1 -= n1; str1 += n1;
sn2 -= n2; str2 += n2;
} else { /* neither or one multibyte */
uc1 = toupper(*str1);
uc2 = toupper(*str2);
if (uc1 != uc2) {
return uc1 uc2 ? -1 : 1;
} else if (uc1 == '\0') {
return 0;
}
sn1--; str1++;
sn2--; str2++;
}
}
return 0;
}
Note this assumes you're running in a UTF-8 locale. I don't know how
you handle locales. Otherwise you'll need to switch out the mbrtowc
functions. But I think the algorithm is sound.
Mike
--
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not
yet been conceived.
Re: Well, the large file offset stuff in smbclient seems to work
On Sat, 15 Feb 2003 21:26:16 -0500 John E. Malmberg [EMAIL PROTECTED] wrote: Michael B. Allen wrote: Richard Sharpe [EMAIL PROTECTED] wrote: Just reporting that the large file offset code in smbclient and libsmb now seems to work. I have been chasing a weird problem with 20+ second delays in completing writes at times, and have got to 130 GB in a file. Heading towards 350GB and later 1TB. Wouldn't anything after 4GB be redundant? No. Strange effects can happen at many different file sizes. If you do not test it, you do not know that it works. Can you give me a specific example? I've written a client and I never tested it past 5-6GB. You have me worried now :-/ Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: Well, the large file offset stuff in smbclient seems to work
On Sat, 15 Feb 2003 23:04:29 -0500 John E. Malmberg [EMAIL PROTECTED] wrote: Michael B. Allen wrote: No. Strange effects can happen at many different file sizes. If you do not test it, you do not know that it works. Can you give me a specific example? I've written a client and I never tested it past 5-6GB. You have me worried now :-/ There may not be a problem in your client. But problems may show up in file systems and the support C library calls. In older systems, bits were precious, so there may be many fields that do not have enough, and now backwards compatability may be showing it's age. Sometimes it is found in a device driver that because at the time a 1GB disk was unimaginable, that the bits above there were used for flags. Some algorithms are sound but do not scale well, hence the unexplained slowdowns. Every 4 bit nybble barrier can be an issue, and the signed/unsigned usage may also be an issue. The granualarity of blocks in the file system. Once you get past 4GB, I would expect the next hiccup may be at the 1TB level and then every power of 2 beyond that. Ok, so you're citing unforseen problems with how libraries, drivers, hardware, etc handle the 64 bit type as opposed to some issue known to the protocol like some bits getting trampled if the field isn't aligned with the planets or some such. How many people are dealing with files larger than 4G on a regular basis? Not many. You can not test every thing though. :-) Yes, even over loopback the process is a too tedious :-) Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: Winbindd limited by select
On Wed, 12 Feb 2003 07:36:19 -0500 Ken Cross [EMAIL PROTECTED] wrote: I've run into a problem with winbindd in both 2.2.x and 3.0 where it just locks up after a while on large, busy networks. We finally tracked down the problem to the fact that the C library select function is limited by default to 256 file descriptors in NetBSD (1024 in FreeBSD, 2048 in Linux). So once 256 (or whatever) smbd processes connected to winbindd, it broke pretty badly and was very hard to kill. This is set at compile-time, not run-time. This line: #define FD_SETSIZE 2048 /* Max # of winbindd connections */ must occur before the first invocation of sys/types. This could be a build option, but it might be much simpler to hard-code it in local.h, which is what I did to fix it. Better still add a check to see if the limit has been reached and return an error. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: Ignoring printer errors
On Mon, 10 Feb 2003 18:44:00 + [EMAIL PROTECTED] wrote: Don't change the printing code. You'll regret it :-) :-). I was also thinking this morning in the shower of moving the error returns to full NTSTATUS for all printing returns... That would make me want to take a shower too. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
NBT length parameter larger than necessary in session request
Hi guys, Ever notice smbclient sends an NBT session request with an NBT length field that is 4 bytes longer than necessary? No harm, but is there a reason for this? I'm using 2.2.1a shipped with RH connecting to the same version of Samba over loopback. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: Win2K: Primary Domain Fld of Ssn Setup Not Properly Zero Term'd
On Mon, 26 Aug 2002 10:24:09 + Luke Kenneth Casson Leighton [EMAIL PROTECTED] wrote: On Sun, Aug 25, 2002 at 10:02:49PM -0400, Allen, Michael B (RSCH) wrote: Clients should not check for *two* zero bytes after the Primary Domain field Unicode string in SMB_COM_SESSION_SETUP_ANDX. You may only get *one* 0x00 byte. I'm almost glad this is a bug in Win2K, I thought this was a bug in jCIFS. At least I have two articles of evidence suggesting the bug is with Win2K. One is inlined here and the other is a PNG of a pcap. Aug 21 06:58:52.472 - bad string 0: FF 53 4D 42 73 00 00 00 00 98 01 80 00 00 00 00 |?SMBs...| 00010: 00 00 00 00 00 00 00 00 05 88 56 34 01 F8 04 00 |..V4.?..| 00020: 03 75 00 81 00 00 00 58 00 7C|.u.X.| len1 = 0x58; len2=0x7c^ ^ 57 00 69 00 6E 00 W.i.n.| 00030: 64 00 6F 00 77 00 73 00 20 00 35 00 2E 00 30 00 |d.o.w.s. .5...0.| 00040: 00 00 57 00 69 00 6E 00 64 00 6F 00 77 00 73 00 |..W.i.n.d.o.w.s.| 00050: 20 00 32 00 30 00 30 00 30 00 20 00 4C 00 41 00 | .2.0.0.0. .L.A.| 00060: 4E 00 20 00 4D 00 61 00 6E 00 61 00 67 00 65 00 |N. .M.a.n.a.g.e.| 00070: 72 00 00 00 44 00 49 00 56 00 49 00 4E 00 45 00 |r...D.I.V.I.N.E.| 00080: 00 30|.0 0x58 length ends here. well, whoopidedoo, that happens to be absolutely spot-on. don't know what the 0x7c is about: it's either an incorrectly-specified max length of the Unicode UCS16 string, or it's something else. more examples would help isolate that. now. who do i send the bill to for my time? Microsoft Corp. PO Box 9876542-1 Redmond, WA 87654-321 -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and more importantly to tasks that have not yet been conceived.
Re: SNIA CIFS TR
On Tue, 30 Jul 2002 20:24:48 +1000 Andrew Bartlett [EMAIL PROTECTED] wrote: I wish someone would do a real analysis and write some practical documentation. A volenteer! Great! I'll see what help I can be, but you might want to This is such a crappy argument. I file this one with the if you don't like it, submit a patch argument. If someone writes some code that does X, the chances of someone else, possibly much more capable, of also writing code to do X decreases greatly. So now the SNIA comes up with a crappy document (nice formatting; too bad it's a MS Word doc) and another group that might have formed a real working group that would turn out to do some good research, generate dependency graphs, maintain a bug database, etc has now gone off and done something else instead. So? But this is the document the CIFS community is working with - and it really is the best we have - despite its' defficiencies. As to 'why SNIA'? Well, SNIA puts on the annual CIFS conference, and MS is a member. Given the need for MS participation in an forum that seriously attempts to document the protocol, and the need for a vender neutral body, I can certainly understand SNIA's role I'm directing my grievances at the working group members and less so the CIFS interests for being irresponsible. I think the attitude of SNIA members is too optimistic for the quality of work being performed. Nothing personal folks but this document is a turd. What makes anyone think Microsoft will implement any changes to their servers even if Leach himself ok's your infolevels? They won't unless they're politically motivated. We're sitting on our hands right now and it's sad. I think MS's participation wavered because they didn't take the WG seriously. There were issues presented to MS that could have been resolved in some Netapp lab by a high school intern. They should have done some real work and *then* approched MS with *real* brain teasers like what some little mystery byte of flags does. If you just ask general questions it's too much work for the arrogant bastards. If the WG had asked very specific questions they would have had much better results and added real content to the document. There needs to be a concerted effort to identify the issues and sort out a definitive position on each. The WG could take a tip from the W3C in this respect. They have open forums for dicussion. Anyone can subscribe to the various mailing lists and contribute. I didn't see *any* discussion on any SNIA mailing list or anywhere else. When I posted a pertinent factoid I never received a message that it was acknowledged or dismissed and why. The W3C keeps everything freely available on Web in HTML and updates it frequently. I have prepared the following page as an example: http://www.eskimo.com/~miallen/cifs/cifs-issues.html I hope the WG considers changing their strategy because I for one think they're making negative progress. -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and more importantly to tasks that have not yet been conceived.
Re: SNIA CIFS TR
Don't you think it's kind of funny that Leach and Naik aren't even mentioned in the acknowledgements? And they put a Copyright 2001, 2002 SNIA in there? This document is a big turd. There are major grammatical errors, technical inaccuracies, and huge holes that aren't even mentioned (what's the number of seconds between 1601 and 1970 again?). How about this gem on page 1: Adoption of a common file sharing protocol having modern semantics such as shared files, byte-range locking, coherent caching, change notification, replicated storage, etc. would provide important benifits to the Internet community. What a load of crap! Who's going to run a CIFS server on the internet? DCE on top of Transactions on top of SMB in front of empty 4 byte NetBIOS headers? No thanks! Don't you think it would be worth mentioning that SMB_COM_COPY doesn't even work? There's *nothing* about DCE/RPC in here except for some incomprehensible banter about PDUs. The only stuff that's accurate is the original Leach/Naik content. The few corrections I submitted have not been fixed so why bother to contibute anything? This document is an excuse for the different shadowy clicks to get their little two-bit extensions in. And the funny thing is the extensions will never be implemented by Windows servers so they're nearly pointless. I wish someone would do a real analysis and write some practical documentation. Sorry. Needed to be said, Mike On Mon, 29 Jul 2002 14:50:26 -0500 Christopher R. Hertel [EMAIL PROTECTED] wrote: Mike, I sent a message to your ml.com address. The SNIA CIFS TR is at: -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and more importantly to tasks that have not yet been conceived.
