From owner-freebsd-hackers Mon Dec 22 16:43:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA14488 for hackers-outgoing; Mon, 22 Dec 1997 16:43:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from helios.dnttm.ru (root@dnttm.wave.ras.ru [194.85.104.197]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA14468 for ; Mon, 22 Dec 1997 16:42:19 -0800 (PST) (envelope-from dima@tejblum.dnttm.rssi.ru) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id DAA17627; Tue, 23 Dec 1997 03:41:05 +0300 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.8/8.8.7) with ESMTP id DAA01959; Tue, 23 Dec 1997 03:36:23 +0300 (MSK) (envelope-from dima@tejblum.dnttm.rssi.ru) Message-Id: <199712230036.DAA01959@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: luoqi@watermarkgroup.com (Luoqi Chen) cc: hackers@freebsd.org Subject: Re: msdosfs win95 long file name support In-reply-to: Your message of "Mon, 22 Dec 1997 10:54:45 EST." <9712221554.AA11732@watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Dec 1997 03:36:23 +0300 From: Dmitrij Tejblum Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Luoqi Chen wrote: > Actually I looked at NetBSD's code before I started. To be honest, i didn't looked at it. I only merged it. > But its lookup code is > somehow not very efficient: directory entry found is stored as directory > relative offset, as opposed to file system relative offset as in our code. ^^^^^^^^^ You mean "old NetBSD code"? :) > This results in extra pcbmap() calls in subsequent vnops (this problem is > somewhat alleviated by the usage of fat cache, though). Hmm. I see, you store begin and end cluster of dir entry in denode. Don't you assume that dir entry can only be in 2 clusters, by a chance? Probably, very long names cannot happen, but it wouldn't look as a good design. > > Their long file name support is not very well designed too. For instance, > if we are to create a file with long file name, we need to find a unique > 8.3 name. The logical place is to do that is in the lookup code, where we > traverse the whole directory. NetBSD's code instead does that in vnops code, > which means that you need to go through the directory TWICE. This is a > Bad Thing(TM) if the directory is very large (say, windows/system :) Oh, indeed, your way seems much better than the NetBSD's. Congratulations. > > - NetBSD support FAT32 (I haven't tested it) > This would be nice to have in our code. I don't know how hard that would be. > I remember read in the mailing-list archive, someone said it was a completely > different beast than FAT16/12. I don't think so. From looking at the NetBSD code, the only differences is that FAT entry is 32-bit, and the root directory has a FAT chain as every other file. There are some new fields in the BPB also. > > > - NetBSD support such things as access time of a file. > Yes, they support creation/access time. But they didn't try hard to set them > correctly. If I've read their code correctly, both creation and access time > are always set to equal to the modification time. No, I think, they set access time if denode has DE_ACCESS flag, and modification time if denode has DE_UPDATE flag. At least, the times seems to be different on my computer. > After all, it is trivial > to add support for them. Sure. Dima