From owner-freebsd-ports Sat Mar 23 21: 0:10 2002 Delivered-To: freebsd-ports@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 86C4937B404 for ; Sat, 23 Mar 2002 21:00:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2O504B17027; Sat, 23 Mar 2002 21:00:04 -0800 (PST) (envelope-from gnats) Date: Sat, 23 Mar 2002 21:00:04 -0800 (PST) Message-Id: <200203240500.g2O504B17027@freefall.freebsd.org> To: freebsd-ports@FreeBSD.org Cc: From: Boris Popov Subject: Re: ports/29704: Imagemagick Identify utility crashes when used on smbfs mounted share Reply-To: Boris Popov Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR ports/29704; it has been noted by GNATS. From: Boris Popov To: Paul Trunley Cc: freebsd-gnats-submit@FreeBSD.org, ppathiakis@homeportfolio.com Subject: Re: ports/29704: Imagemagick Identify utility crashes when used on smbfs mounted share Date: Sun, 24 Mar 2002 10:58:24 +0600 (ALMT) On Fri, 22 Mar 2002, Paul Trunley wrote: > I believe that this is a problem with smbfs and not with the Identify > utility. I've included a small program that demonstrates the issue. On > local filesystems it is permissable to close an fd that had previously been > mmap'd. The mmap'd region is still accessable. On an smbfs file this > results in a segmenation fault when the region is accessed. > > Boris, I'm working on a patch to fix the problem. If you want some more > details please feel free to contact me. Yes, this is an expected behavior - smbfs uses a counter to track open/close operations and if it became zero, an SMB "close" request sent to server. Obviously, mmap() doesn't give additional VOP_OPEN() call and file is really closed after close(), so any subsequent read/write operation will fail. In the DOS/Windows world it is normal to have strong relation between open/close operations, while VOP_OPEN()/VOP_CLOSE() in FreeBSD do not match sometime (I'm suspect that it is possible to remove inconsistence, though). One of the possible solutions is to remove smb_close request from smbfs_close() vop and leave it only in the smbfs_inactive(), but this will not allow programs to immediately release a file by just closing it. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message