Date: Sat, 28 Oct 2000 09:14:09 +0700 (ALMST) From: Boris Popov <bp@butya.kz> To: Terry Lambert <tlambert@primenet.com> Cc: Chris Dillon <cdillon@wolves.k12.mo.us>, Shawn Halpenny <malachai@iname.com>, freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: smbfs-1.3.0 released Message-ID: <Pine.BSF.4.10.10010280855530.59778-100000@lion.butya.kz> In-Reply-To: <200010272355.QAA02252@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 Oct 2000, Terry Lambert wrote: > > So... the case-insensitivity only happens at the root of the mount. > > Should it happen everywhere? It'd be nice if it did. :-) > > Ha! > > The full path is sent over the wire. > > The attempt to be "case sensitive on storage, case insensitive on > lookup" is inhernetly flawed. Actually, smbfs doesn't try to be case insensitive. At this moment it merely passes file names with possible charset translation. If long names is not used (WfWg for example), then file names converted to upper case. nwfs have more complex case management features (see mount_nwfs(4) for '-c' option). > The difference is that if you are iterating and comparing in > user space, you will get a failure, but if you are doing an > explicit VOP_LOOKUP in kernel space, the case folding will work. Hmm, why ? > The problem is that you don't really get a directory handle > object, like you get an inode in NFS, since in a DOS FS, and > thus in the wire externalization of a DOS FS, which is what SMB > gives you, the directory entry itself _is_ the inode, not a > pointer to an independent object which dereferences to the inode. > I think that if you disable the attempted case folding in the > SMBFS VOP_LOOKUP code, your problem will go away. Not exactly so - case sensitivity depends on server, for most servers ls /A and ls /a are the same, but NT have strange behavior for root directory and not all directories are case insensitive. > NB: Another approach would be to fold everything to lower case > in both VOP_LOOKUP and VOP_READDIR; this could be accomplished > using a mount option. If you wanted to be more Windows-like, > you could make the first letter upper case, and subsequent > letters lower case. I'm unsure if this correct, because long file names used on windows platform may have more than one upper case letter (Program Files for example). > NNNB: If you are using a Samba server as the server, and short > names, you are probably screwed, since short names on a Samba > server are synthetic, and indeterminately so. On a Windows > box, if I rename (short:long) "PROGRA~1":"Program Files" to > "PROGRA~7", I get "PROGRA~7":"PROGRA~7"; if I then rename > "PROGRA~7" to "Program Files", I get "PROGRA~7":"Program Files". > Since the Samba short namespace is synthetic even if the UNIX > FS underneath supports both name spaces (since the UNIX name > API is handicapped, compared to the Macintosh or Windows API), > you will get a short name based on the inode number. Correct and it is not recommended to use 8.3 name space with Samba. > As to the df/du problem, I'd suggest hacking VFS_STAT to return > fake data, and then figure out why it's failing so catastrophically, > since the problem is there. I suspect the problem is that it is > an old VFS_STAT call that is being called, and that a new VFS_STAT > struct is being copied out in all cases, instead of making sure it > is old vs. new, and doing the right thing, and the resulting > buffer overrun stomps on something important. No, this is not related. The same things will happen on all SMB requests if server dropped the connection and it seems to be fixed in the upcoming smbfs-1.3.1. On a side note I'm unsure why NT server drops the connection if client doesn't send any request in XX minutes (for example Samba uses NetBIOS keepalive packets). -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10010280855530.59778-100000>