Date: Fri, 27 Oct 2000 23:55:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cdillon@wolves.k12.mo.us (Chris Dillon) Cc: malachai@iname.com (Shawn Halpenny), bp@butya.kz (Boris Popov), freebsd-hackers@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: smbfs-1.3.0 released Message-ID: <200010272355.QAA02252@usr01.primenet.com> In-Reply-To: <Pine.BSF.4.21.0010271152370.16493-100000@mail.wolves.k12.mo.us> from "Chris Dillon" at Oct 27, 2000 12:01:48 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Oh yeah, I've noticed one more thing. When you're at the root of a > mount, you can cd into a directory using any case, but if you get the > case wrong, you don't get a listing. Here's an example: [ ... ] > 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. The way this works on OSs which support it is that the globbing occurs in the kernel. This lets the case folding occur before the data is returned. 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. 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 suspect that this is at the heart of your lookup problems, given the way that UNIX programs tend to put in what they were given out. I think that if you disable the attempted case folding in the SMBFS VOP_LOOKUP code, your problem will go away. Note: things which reference explicit names use VOP_LOOKUP, while things which iterate directories use VOP_READDIR. I suspect that you will see similar problems on attempts to rename things, because of this. 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. NNB: The behaviour will also depend on the server you are using; some servers can return both the short (8.3) and long names over SMB, and others can only return the short names. 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. --- 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200010272355.QAA02252>