From owner-freebsd-fs Mon Nov 20 13:16:29 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C541F37B4C5 for ; Mon, 20 Nov 2000 13:16:26 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id OAA15150; Mon, 20 Nov 2000 14:12:16 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAxOaqBD; Mon Nov 20 14:12:04 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA01210; Mon, 20 Nov 2000 14:16:09 -0700 (MST) From: Terry Lambert Message-Id: <200011202116.OAA01210@usr08.primenet.com> Subject: Re: MSDOS FS and flock? To: marc.vanwoerkom@science-factory.com (Marc van Woerkom) Date: Mon, 20 Nov 2000 21:16:08 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <200011201400.eAKE0T613531@nil.science-factory.com> from "Marc van Woerkom" at Nov 20, 2000 03:00:29 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I wonder why Emacs' movemail program is not able to move > mail on a MSDOS partion. > Under Linux this seems to be no problem (or no visible > problem yet :-) > > My guess is that msdosfs does not allow flock(). > > Questions: > 1) Might this be true? > And if yes, would flock()ing be necessary - the > msdosfs code might do such already. > > 2) Does anyone have a patch to movemail or > msdosfs? The lock lists are hung off the in-core inode, not the vnode. This means that locking doesn't work, except on VFS that implement VOP_ADVLOCK by applying a lock to the underlying backing objects. This also means that, since a VOP_ADVLOCK entry is required, flock() doesn't work on FreeBSD on special devices, sockets, or named pipes (all of which have a struct fileops different from the standard VFS struct fileops), since the flock() entry point ignores everything but standard VFS'. The way to correct this is to move all but veto processing out of the per VFS code, and hang the lock list off the vnode instead (veto processing needs to remain to support coelesce across multiple stacking layers, as well as layers with multiple exposures, where the lock lists of two or more vnodes need to appear as a single lock space. This also implies that not only pid is needed to uniquify namespace, and system ID (for NFS support), but _also_ a VFS ID: otherwise there will be an erroneous attempt to coelesce locks from an upper layer in a lower layer, when the upper and lower layer are simultaneously exposed into the file system namespace, and locks are asserted into both layers (this is a detail that would prevent VFS stacking from working correctly, were it not implemented). What version of the OS are you running? I could provide a set of patches against 4.1, if you absolutely needed it, but I doubt it would be carried forward in FreeBSD -HEAD, which I have to say I'm not going to touch right now. 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-fs" in the body of the message