Messages in this thread | | | Date | Tue, 17 Feb 2004 19:27:28 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: UTF-8 and case-insensitivity |
| |
On Tue, 17 Feb 2004, H. Peter Anvin wrote: > > Well, this is also true :) I still say it belongs in userspace.
The thing is, I do agree with Tridge on one simple fact: it's very hard indeed to do atomic file operations from user space.
That's not necessarily a problem if samba is the only process accessing the directories in question, since then samba could do all locking internally and make sure that it never does anything inconsistent.
However, clearly people who run samba on a machine want to potentially _also_ export that same filesystem as a NFS volume, as a way to have both Windows and UNIX clients access the same data. And that pretty much means that other people _will_ access the directories, and that samba can't do its internal locking in that kind of environment.
This is why I am symphathetic to the need to add _some_ kind of support for this. And the only common place ends up being the kernel.
> For 100% bug-compatibility with Windows, though, it is probably > worthwhile to have the filename in the native filesystem be not what a > Windows user would see, but rather the normalized filename. That makes > a userspace implementation much easier.
Oh, absolutely. But that's something that samba can easily do internally: it can choose to just entirely ignore filenames that aren't normalized, or it can export it on the wire (obviously in the normalized UCS-2 format), and just consider non-normalized names to be another "case". In fact, that's what the naive implementation would do anyway, so that's not any added complexity.
(And samba clearly _cannot_ show the client a non-normalized name per se, since the smb protocol ends up using UCS-2).
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |