From owner-freebsd-gnome@FreeBSD.ORG Mon Aug 30 16:22:31 2010 Return-Path: Delivered-To: gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA891065670; Mon, 30 Aug 2010 16:22:29 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id E64588FC14; Mon, 30 Aug 2010 16:22:28 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o7UGMRRE000803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Aug 2010 09:22:27 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 2FAAE1CC3C; Mon, 30 Aug 2010 09:22:27 -0700 (PDT) To: Joe Marcus Clarke In-reply-to: Your message of "Sun, 29 Aug 2010 13:49:34 EDT." <4C7A9DAE.4090702@freebsd.org> Date: Mon, 30 Aug 2010 09:22:27 -0700 From: "Kevin Oberman" Message-Id: <20100830162227.2FAAE1CC3C@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-30_07:2010-08-30, 2010-08-30, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008300099 Cc: gnome@freebsd.org, Andriy Gapon Subject: Re: ports/149134: x11/gnome2 unable to unmount UFS file system X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 16:22:31 -0000 > Date: Sun, 29 Aug 2010 13:49:34 -0400 > From: Joe Marcus Clarke > > On 8/29/10 12:57 PM, Kevin Oberman wrote: > >> Date: Sun, 29 Aug 2010 12:22:20 -0400 > >> From: Joe Marcus Clarke > >> Sender: owner-freebsd-gnome@freebsd.org > >> > >> On 8/29/10 5:29 AM, Andriy Gapon wrote: > >>> on 29/08/2010 01:18 Joe Marcus Clarke said the following: > >>>> On 8/28/10 4:02 PM, Andriy Gapon wrote: > >>>>> on 28/08/2010 22:28 Joe Marcus Clarke said the following: > >>>>>> > >>>>>> Try http://www.marcuscom.com/downloads/patch-hald_hf-storage.c > >>>>> > >>>>> Just wondering aloud... Would the same strange things (mentioned in the comment > >>>>> in the patch) happen with labels for other filesystems like msdos/ cd9660/ ? > >>>>> Or it's something specific to UFS? > >>>>> > >>>> > >>>> Yeah, it could happen for other labels, I suppose. The problem is that > >>>> the labels that appear dynamically depending oh whether or not a device > >>>> is mounted confuses hal. If someone mounts /dev/cd0, unmounts it, then > >>>> sees /dev/cd9660/FREEBSD appear, that will cause hal to think a new > >>>> device was inserted. > >>>> > >>>> That said, I've only seen this happen with UFS. > >>> > >>> > >>> BTW, there seems to be an exclamation mark missing in the following part of the > >>> patch (hope you use monospaced font): > >>> > >>> + ! strcmp(fields[1], "PART")) && > >>> + ! (strncmp(fields[2], "ufsid/", strlen("ufsid/")) || > >>> Here----------^ > >>> + ! strncmp(fields[2], "ufs/", strlen("ufs/")))) > >>> > >>> > >> > >> Ugh, you're right. When I added "ufs/" to the list, I broke the logic. > >> It should be fixed now. > > > > That explains some of the weirdness I've been seeing. > > > > I'm really embarrassed as I found the error in the patch for 2.28 and > > fixed it (somewhat differently as I demorganized the logic and changed an > > || to an &&) and then THOUGHT I had confirmed that the patch to 2.30 > > included my fix. Don't know how I missed it. :-( And, yes, I did post a > > note about the broken logic back on Feb. 23. > > > > "I just actually looked at the patch above and I think the problem is > > that the second line needs to end with || and not &&. I just re-built > > hal with this and I will give it a shot after lunch." > > > > Looks like I neglected to send a confirmation that it did work, though. > > Thanks for catching it, Andriy. > > > > I can confirm that it is working, now. I suspect that the logic error > > was really the only problem and that the two lines you added to the > > patch are superfluous. I have not seen any indication that they cause > > any problems, but I have not done really rigorous testing, either. > > No, the other patch can help as well as it will prevent unnecessary > churn when those other device nodes show up. Thanks for testing. Joe, All testing is complete. I see only one, non-critical issue. When I dismount a geli encrypted FS, frequently I get an error that the directory in /media could not be deleted. I suspect that this is an race condition cause by the geli device vanishing on the dismount. (I attach geli devices with '-d'.) This is a minor annoyance that I have largely resolved by adding "sudo /bin/rmdir /media/*" to my .xinitrc. It's only a problem if I need to re-mount the same FS during the same Gnome session. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751