From owner-freebsd-ports Mon Apr 8 22:50: 8 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 EBFBA37B405 for ; Mon, 8 Apr 2002 22:50:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g395o2089486; Mon, 8 Apr 2002 22:50:02 -0700 (PDT) (envelope-from gnats) Date: Mon, 8 Apr 2002 22:50:02 -0700 (PDT) Message-Id: <200204090550.g395o2089486@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: Tue, 9 Apr 2002 12:42:48 +0700 (ALMST) On Fri, 29 Mar 2002, Paul Trunley wrote: > I took your advice and tried this out and it seems to work well. It > certainly solves the mmap issue. I don't think that this changes the ability > for a file to be released upon close because the system will call inactive > immediately after the last close, so the effect is the same as doing the smb > close request in the close vop. > > I've attached a patch I put together that implements this change, I've done a > little testing and it seems to work ok, but nothing exhaustive. The patch looks good. However, it may cause wrong time stamps on some servers which require a non-zero last access time value in the SMB_CLOSE request. > This patch is a minimal change, but it might be better to replace n_opencount > with a single bit in the n_flag member of the smbnode structure, since there > isn't really a need to remember the number of opens. All that needs to be > remembered is if the file is currently open or not. n_opencount is still useful for various diagnostics, so it probably will stay. Thanks for helping on this issue! P.S. sorry for delay - swamped by my work :( -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message