From owner-freebsd-arch@FreeBSD.ORG Mon Apr 15 19:57:20 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E81DD6D2 for ; Mon, 15 Apr 2013 19:57:20 +0000 (UTC) (envelope-from 3oFtsUQUTDJkmBF4H9BE47KMH.FR94BS.5HF8K774L6-3K5AiK77evg.HK9@photos-server.bounces.google.com) Received: from mail-da0-x249.google.com (mail-da0-x249.google.com [IPv6:2607:f8b0:400e:c00::249]) by mx1.freebsd.org (Postfix) with ESMTP id CA114171B for ; Mon, 15 Apr 2013 19:57:20 +0000 (UTC) Received: by mail-da0-f73.google.com with SMTP id w3so158325dad.0 for ; Mon, 15 Apr 2013 12:57:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.115.204 with SMTP id jq12mr2668103pbb.8.1366055840505; Mon, 15 Apr 2013 12:57:20 -0700 (PDT) Message-ID: Date: Mon, 15 Apr 2013 19:57:20 +0000 Subject: Freight forwarder & logistics provider shared an album with you. From: "Freight forwarder & logistics provider" To: freebsd-arch@FreeBSD.org Content-Type: multipart/related; boundary=e89a8ff245c51ddff604da6ba9ad X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Freight forwarder & logistics provider List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:57:21 -0000 --e89a8ff245c51ddff604da6ba9ad Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 RGVhciBNeSBGcmllbmQNCg0KICAgICAgICAgIE5pY2UgZGF5LCBIeXVuIFlvdW5nIGlzIGEgbGVh ZGluZyBwcm9mZXNzaW9uYWwgZnJlaWdodCBmb3J3YXJkZXINCmFuZCBsb2dpc3RpY3MgcHJvdmlk ZXIgd2hvIGZvY3VzIG9uIHRoZSBzaGlwbWVudCBmcm9tIFNvdXRoIENoaW5hIHRvIGFsbA0KdGhl IHdvcmxkLiBIeXVuIFlvdW5nIHN0YXJ0ZWQgZnJlaWdodCBmb3J3YXJkaW5nIG9wZXJhdGlvbiBh dCBTaGVuemhlbiBpbg0KMjAwNC4gQmFzZWQgYXQgU2hlbnpoZW4sIG91ciBhbWJpdGlvbiBoYXZl IHB1c2hlZCB1cyBmb3J3YXJkIHRvIGV4cGFuZCB0bw0Kb3RoZXIgY2l0aWVzIGluIHNvdXRoIG9m IENoaW5hLiBOb3cgd2UgaGF2ZSBjYXBhY2l0eSBvZiBoYW5kaW5nIHNoaXBtZW50IHRvDQpvciBm cm9tIGFsbCB0aGUgcG9ydHMgaW4gc291dGggb2YgQ2hpbmEuDQogICAgICAgICAgICBIb2xkcyB3 aGlsZSB3aG9sZSAtIGhlYXJ0ZWRseSBhY2hpZXZlcyB0aGUgYmVzdCBlbnRlcnByaXNlDQpvYmpl Y3RpdmUsIFdpdGggdGhlIGdyZWF0IHN1cHBvcnQgb2Ygb3VyIGdsb2JhbCBhZ2VuY3ksIHdlIHBy b3ZpZGUgc2VydmljZXMNCnRvIG91ciBjdXN0b21lcnMgdGhyb3VnaCBwcm9jZXNzLWRyaXZlbiBv cGVyYXRpb24gdGVhbSwgYWR2YW5jZWQNCmluZm9ybWF0aW9uIHN5c3RlbSwgYW5kIHN0cm9uZyBt YW5hZ2VtZW50IHRlYW0uDQoNCkdsYW5jZSB0byBvdXIgY29tcGFueToNCjEuIFNlYSBGcmVpZ2h0 LCBpbmNsdWRlZCBGQ0wmTENMOw0KMi4gQWlyIEZyZWlnaHQ7DQozLiBFeHByZXNzLCBpbmNsdWRl ZCBESEwsVVBTLEZFREVYLFNBR0FXQSBhbmQgU0NPUkVKUDsNCjQuIEltcG9ydCAmIEV4cG9ydDsN CjUuIExhbmQgVHJhbnNwb3J0YXRpb24uDQoNCiAgICAgICAgICAgIFdlIHNlZWsgbm8gc3Ryb25n ZXN0IG9ubHkgbW9yZSBzcGVjaWFsaXplZCwgc2VuaW9yLiBZb3VyDQpzYXRpc2ZpZWQgd2lsbCBi ZSBvdXIgbWF4aW1hbCBwcmlkZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2hlbnpoZW4gSHl1 biBZb3VuZyBJbnRlcm5hdGlvbmFsIFRyYW5zcG9ydGF0aW9uIENPLixMVEQNCkphY2t5IFlhbmcN Cg0KQWRkOiBGbG9vciA3JjgsIFNvdXRoIEJhb5JhbiBSb2FkLCBMdW9odSBEaXN0cmljdCwgU2hl bnpoZW4sIEd1YW5nZG9uZywNCkNoaW5hLg0KDQpodHRwczovL3BpY2FzYXdlYi5nb29nbGUuY29t L2xoL3NyZWRpcj91bmFtZT0xMDA4MjMyMzYwNzM3NDI3MjcwMjQmdGFyZ2V0PUFMQlVNJmlkPTU4 NjcxNjUwOTU2MDAyNDUyMTcmYXV0aGtleT1HdjFzUmdDT0dxaG82bDZaTG9FdyZpbnZpdGU9Q056 dTdaOEMmZmVhdD1lbWFpbA0K --e89a8ff245c51ddff604da6ba9ad-- From owner-freebsd-arch@FreeBSD.ORG Wed Apr 17 11:09:57 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8A479DA8 for ; Wed, 17 Apr 2013 11:09:57 +0000 (UTC) (envelope-from editor@ijtemt.org) Received: from Host1.yourdomainname.com (50.22.181.244-static.reverse.softlayer.com [50.22.181.244]) by mx1.freebsd.org (Postfix) with ESMTP id 732B1EC2 for ; Wed, 17 Apr 2013 11:09:57 +0000 (UTC) X-Sender: "Editor IJTEMT" X-Receiver: freebsd-arch@freebsd.org From: "Editor IJTEMT" To: freebsd-arch@freebsd.org Date: 17 Apr 2013 04:07:21 -0700 Subject: Call for Papers IJTEMT. Kindly impart in your University/Organization/College/Colleagues/Academia/Social Circle. Priority: urgent Importance: normal Message-Id: <20130417110957.8A479DA8@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Editor IJTEMT List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:09:57 -0000 INTERNATIONAL JOURNAL OF TRENDS IN ECONOMICS MANAGEMENT & TECHNOLOGY IJTEMT invites you to submit your research paper for publishing in Volume II, Issue II ( April 2013). CALL FOR PAPERS VOLUME II, ISSUE II www.ijtemt.org About IJTEMT International Journal of Trends in Economics Management and Technology (IJTEMT) in an International Academic Journal e-published bimonthly in India and open to the world. In this present interdisciplinary era, here at IJTEMT, a group of intellectual came together to find a common platform for three major components of any economy i.e., Economics, Management and Technology. Here we provide a forum to bridge the gap between the brushed-up professional in their respective fields and the new researcher which will results in better understanding and fruitful outcomes. The focus of this journal is to publish paper on economics management and technology. Submitted papers are reviewed by a full double blind manner by the technical committee of the journal. The audience for the journal is professionals from related fields, academicians and new students & research scholars. All submitted articles should report original, previously unpublished research results, experimental or theoretical, and will be peer-reviewed. Articles submitted to the journal should meet these criteria and must not be under consideration for publication elsewhere. Manuscripts should follow the style of the journal and are subject to both review and editing. Why Select IJTEMT Journal IJTEMT Provides E-Certificates to Author's if Needed.IJTEMT is Globally Approved International Journal having Strong Editorial Board. This is Online Open Journal .Author's can Download Paper from Library of Journal at any Time from Anywhere.IJTEMT is a Association of Eminent Scientist, Researchers and Experienced Members of More than 20 Countries.IJTEMT Publishes High Quality Papers which are Peer Reviewed by International/National Reviewers. Author's Query can be solved within 18 Hours. Subject Category: ECONOMICS, MANAGEMENT & TECHNOLOGY. Important Dates: Paper Submission: 27th April 2013 Review Results (Acceptance/Rejection) Notification: Within two weeks after submitting manuscript. Guidelines for submission and Review Process: IJTEMT welcomes author submission of papers concerning any branch of the economics, management and technology and their applications in business, industry and other subjects relevant. The review process goes through following phases which can take time from ten days to two months: a. Each manuscript will be initially evaluated by the editorial board / editor, who may make use of appropriate software to examine the originality of the contents of the manuscript. b. The manuscripts passed through screening at above noted level will be forwarded to two referees for blind peer review, each of whom will make a recommendation to publish the article in its present form/edit/reject. During this period referees shall treat the contents of papers under review as privileged information. c. The reviewers' recommendations determine whether a paper will be accepted / accepted subject to change / subject to resubmission with significant changes / rejected. d. For papers which require changes, the same reviewers will be used to ensure that the quality of the revised paper is acceptable. e. All papers are refereed, and the Editor-in-Chief reserves the right to refuse any typescript, whether on invitation or otherwise, and to make suggestions and/or modifications before publication. Submission of Paper will takes place in two phases: a. Initial Paper Submission: Prospective author (s) is/are encouraged to submit their manuscript including charts, tables, figures and appendixes in .pdf and .doc (both) format to e-mail: [1]submit@ijtemt.org. All submitted articles should report original, previously unpublished research results, experimental or theoretical. Articles submitted to the IJIMT should meet these criteria and must not be under consideration for publication elsewhere. b. Camera Ready Paper Submission:On the acceptance of the paper after completion of the review process the author (s) is/are has to submit camera ready full text paper in .doc and .pdf (both) format to e-mail: [2]submitfinal@ijtemt.org along with the corresponding signed copy of copyright transfer form and scanned copy of payment slip. Publication fees Each accepted paper will be charged, for publication and paper handling, 5000 INR per paper (for a maximum of 8 pages, above which 100 INR will be charged for every additional page) for Indian nationals where as publication fees for foreign national will be 100 USD per paper (for a maximum of 8 pages, above which 10 USD will be charged for every additional page) which is to be paid as per the instructions mentioned in the letter of acceptance of the manuscript submitted. Editor International Journal of Trends in Economics Management & Technology Website: [3]www.ijtemt.org Email: [4]editor@ijtemt.org, [5]coedtech@ijtemt.org, [6]contact@ijtemt.org. Paper Submission Email: [7]submit@ijtemt.org. References 1. mailto:submit@ijtemt.org 2. mailto:submitfinal@ijtemt.org 3. http://www.ijtemt.org/ 4. mailto:editor@ijtemt.org 5. mailto:coedtech@ijtemt.org 6. mailto:contact@ijtemt.org 7. mailto:submit@ijtemt.org From owner-freebsd-arch@FreeBSD.ORG Wed Apr 17 23:15:50 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9910B69 for ; Wed, 17 Apr 2013 23:15:50 +0000 (UTC) (envelope-from meridiansnc31@optus.com.au) Received: from compon.lnk.telstra.net (compon.lnk.telstra.net [203.45.202.126]) by mx1.freebsd.org (Postfix) with ESMTP id CE3D8D1E for ; Wed, 17 Apr 2013 23:13:57 +0000 (UTC) Received: from [71.13.195.53] (helo=lesuxfxyxpd.shcohmf.tv) by compon.lnk.telstra.net with esmtpa (Exim 4.69) (envelope-from ) id 1MMI7X-9063ju-00 for arch@freebsd.org; Thu, 18 Apr 2013 09:13:59 +1000 Received: from 203.13.126.242 (EHLO mail4.optus.com.au) (203.13.126.242) by mta450.mail.re4.yahoo.com with SMTP; Thu, 18 Apr 2013 09:13:59 +1000 Received: from mail1.optus.com.au ([203.13.126.129]) by mail4.optus.com.au; Thu, 18 Apr 2013 09:13:59 +1000 From: mms-noreply@optus.com.au To: Subject: Optus MMS Service from 61593273130@optusmobile.com.au Date: Thu, 18 Apr 2013 09:13:59 +1000 Message-Id: <4650222.0728884300129.JavaMail.SYSTEM@2NB198VPC5A4T> X-Priority: 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=a__penn_67_72_47" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 23:15:50 -0000 ------=a__penn_67_72_47 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Optus MMS ServicePlease refer to attached file for your MMSThanks, OptusI= LLEGAL ACTIVITYYou must not use the service for any activity that breache= s any law or violates any local, state, federal or international law, ord= er, regulation or industry code of practice. ------=a__penn_67_72_47-- From owner-freebsd-arch@FreeBSD.ORG Thu Apr 18 18:49:53 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 360AB935; Thu, 18 Apr 2013 18:49:53 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id BE290138E; Thu, 18 Apr 2013 18:49:52 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id r3IInpvi019293; Thu, 18 Apr 2013 12:49:51 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id r3IInp7l019292; Thu, 18 Apr 2013 12:49:51 -0600 (MDT) (envelope-from ken) Date: Thu, 18 Apr 2013 12:49:51 -0600 From: "Kenneth D. Merry" To: Bruce Evans Subject: Re: patches to add new stat(2) file flags Message-ID: <20130418184951.GA18777@nargothrond.kdm.org> References: <20130307000533.GA38950@nargothrond.kdm.org> <20130307222553.P981@besplex.bde.org> <20130308232155.GA47062@nargothrond.kdm.org> <20130310181127.D2309@besplex.bde.org> <20130409190838.GA60733@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130409190838.GA60733@nargothrond.kdm.org> User-Agent: Mutt/1.4.2i Cc: arch@FreeBSD.org, fs@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 18:49:53 -0000 On Tue, Apr 09, 2013 at 13:08:38 -0600, Kenneth D. Merry wrote: > On Sun, Mar 10, 2013 at 19:21:57 +1100, Bruce Evans wrote: > > On Fri, 8 Mar 2013, Kenneth D. Merry wrote: > > > > >On Fri, Mar 08, 2013 at 00:37:15 +1100, Bruce Evans wrote: > > >>On Wed, 6 Mar 2013, Kenneth D. Merry wrote: > > >> > > >>>I have attached diffs against head for some additional stat(2) file > > >>>flags. > > >>> > > >>>The primary purpose of these flags is to improve compatibility with CIFS, > > >>>both from the client and the server side. > > >>>... > > >> > > >>I missed looking at the diffs in my previous reply. > > >> > > >>% --- //depot/users/kenm/FreeBSD-test3/bin/chflags/chflags.1 2013-03-04 > > >>17:51:12.000000000 -0700 > > >>% +++ /usr/home/kenm/perforce4/kenm/FreeBSD-test3/bin/chflags/chflags.1 > > >>2013-03-04 17:51:12.000000000 -0700 > > >>% --- /tmp/tmp.49594.86 2013-03-06 16:42:43.000000000 -0700 > > >>% +++ /usr/home/kenm/perforce4/kenm/FreeBSD-test3/bin/chflags/chflags.1 > > >>2013-03-06 14:47:25.987128763 -0700 > > >>% @@ -117,6 +117,16 @@ > > >>% set the user immutable flag (owner or super-user only) > > >>% .It Cm uunlnk , uunlink > > >>% set the user undeletable flag (owner or super-user only) > > >>% +.It Cm system , usystem > > >>% +set the Windows system flag (owner or super-user only) > > >> > > >>This begins unsorting of the list. > > > > > >Fixed. > > > > > >>It's not just a Windows flag, since it also works in DOS. > > > > > >Fixed. > > > > Thanks. Hopefully all the simple bugs are fixed now. > > > > >>"Owner or" is too strict for msdosfs, since files can only have a > > >>single owner so it is controlling access using groups is needed. I > > >>use owner root and group msdosfs for msdosfs mounts. This works for > > >>normal operations like open/read/write, but fails for most attributes > > >>including file flags. msdosfs doesn't support many attributes but > > >>this change is supposed to add support for 3 new file flags so it would > > >>be good if it didn't restrict the support to root. > > > > > >I wasn't trying to change the existing security model for msdosfs, but if > > >you've got a suggested patch to fix it I can add that in. > > > > I can't think of anything better than making group write permission enough > > for attributes. > > > > msdosfs also has some style bugs in this area. It uses VOP_ACCESS() > > with VADMIN for the non-VA_UTIMES_NULL case of utimes(), but for all > > other attributes it hard-codes a direct uid check followed a > > priv_check_cred() with PRIV_VFS_ADMIN. VADMIN requires even more than > > user write permission for POSIX file systems and using it unchanged > > for all the attributes would be even more restrictive unless we changed > > it, but it would be easier to make it uniformly less restrictive for > > msdosfs by using it consistently. > > > > Oops, that was in the old version of ffs. ffs now has related > > complications and unnecessary style bugs (verboseness and misformatting) > > to support ACLs. It now uses VOP_ACCESSX() with VWRITE_ATTRIBUTES for > > utimes(), and VOP_ACCESSX() with other VFOO for all attributes except > > flags. It still uses VOP_ACCESS() with VADMIN() for flags. > > > > >>... > > >>% .It Dv SF_ARCHIVED > > >>... > > >>% +Filesystems in FreeBSD may or may not have special handling for this > > >>flag. > > >>% +For instance, ZFS tracks changes to files and will clear this bit when > > >>a > > >>% +file is updated. > > >>% +UFS only stores the flag, and relies on the application to change it > > >>when > > >>% +needed. > > >> > > >>I think that is useless, since changing it is needed whenever the file > > >>changes, and applications can do that (short of running as daemons and > > >>watching for changes). > > > > > >Do you mean applications can't do that or can? > > > > Oops, can't. > > > > It is still hard for users to know how their file system supports. > > Even programmers don't know that it is backwards :-). > > > > >>% --- //depot/users/kenm/FreeBSD-test3/sys/fs/msdosfs/msdosfs_vnops.c > > >>2013-03-04 17:51:12.000000000 -0700 > > >>% +++ > > >>/usr/home/kenm/perforce4/kenm/FreeBSD-test3/sys/fs/msdosfs/msdosfs_vnops.c > > >>2013-03-04 17:51:12.000000000 -0700 > > >>% --- /tmp/tmp.49594.370 2013-03-06 16:42:43.000000000 -0700 > > >>% +++ > > >>/usr/home/kenm/perforce4/kenm/FreeBSD-test3/sys/fs/msdosfs/msdosfs_vnops.c > > >>2013-03-06 14:49:47.179130318 -0700 > > >>% @@ -345,8 +345,17 @@ > > >>% vap->va_birthtime.tv_nsec = 0; > > >>% } > > >>% vap->va_flags = 0; > > >>% + /* > > >>% + * The DOS Archive attribute means that a file needs to be > > >>% + * archived. The BSD SF_ARCHIVED attribute means that a file has > > >>% + * been archived. Thus the inversion here. > > >>% + */ > > >> > > >>No need to document it again. It goes without saying that ARCHIVE > > >>!= ARCHIVED. > > > > > >I disagree. It wasn't immediately obvious to me that SF_ARCHIVED was > > >generally used as the inverse of the DOS Archived bit until I started > > >digging into this. If this helps anyone figure that out more quickly, it's > > >useful. > > > > The surprising thing is that it is backwards in FreeBSD and not really > > supported except in msdosfs. Now several file systems have the comment > > about it being inverted, but man pages still don't. > > I made the change to UF_ARCHIVE, and updated the man pages. > > > >>% @@ -420,12 +429,21 @@ > > >>% if (error) > > >>% return (error); > > >>% } > > >> > > >>The permissions check before this is delicate and was broken and is > > >>more broken now. It is still short-circuit to handle setting the > > >>single flag that used to be supported, and is slightly broken for that: > > >>- unprivileged user asks to set ARCHIVE by passing !SF_ARCHIVED. We > > >> allow that, although this may toggle the flag and normal semantics > > >> for SF flags is to not allow toggling. > > >>- unprivileged user asks to clear ARCHIVE by passing SF_ARCHIVED. We > > >> don't allow that. But we should allow preserving ARCHIVE if it is > > >> already clear. > > >>The bug wasn't very important when only 1 flag was supported. Now it > > >>prevents unprivileged users managing the new UF flags if ARCHIVE is > > >>clear. Fortunately, this is the unusual case. Anyway, unprivileged > > >>users can set ARCHIVE by doing some other operation. Even the chflags() > > >>operation should set ARCHIVE and thus allow further chflags()'s that now > > >>keep ARCHIVE set. Except it is very confusing if a chflags() asks for > > >>ARCHIVE to be clear. This request might be just to try to preserve > > >>the current setting and not want it if other things are changed, or > > >>it might be to purposely clear it. Changing it from set to clear should > > >>still be privileged. > > > > > >I changed it to allow setting or clearing SF_ARCHIVED. Now I can set or > > >clear the flag as non-root: > > > > Actually, it seems OK, since there are no old or new SF_ immututable flags. > > Some of the actions are broken in the old and new code for directories -- > > see below. > > > > >>See the more complicated permissions check in ffs. It would be safest > > >>to duplicate most of it, to get different permissions checking for the > > >>SF and UF flags. Then decide if we want to keep allowing setting > > >>ARCHIVE without privilege. > > > > > >I think we should allow getting and setting SF_ARCHIVED without special > > >privileges. Given how it is generally used, I don't think it should be > > >restricted to the super-user. > > > > I don't really like that since changing the flags is mainly needed for > > the failry privileged operation of managing other OS's file systems. > > However, since we're mapping the SYSTEM flag to a UF_ flag, the SYSTEM > > flag will require less privilege than the ARCHIVE flag. This is backwards, > > so we might as well require less privilege for ARCHIVE too. I think we, > > that is, you should use a new UF_ARCHIVE flag with the correct sense. > > Okay, done. The patches are attached with UF_ARCHIVE used instead of > SF_ARCHIVED, with the sense reversed. > > > >Can you provide some code demonstrating how the permissions code should > > >be changed in msdosfs? I don't know that much about that sort of thing, > > >so I'll probably spend an inordinate amount of time stumbling > > >through it. > > > > Now I think only cleanups are needed. > > Okay. > > > >>% return EOPNOTSUPP; > > >>% if (vap->va_flags & SF_ARCHIVED) > > >>% dep->de_Attributes &= ~ATTR_ARCHIVE; > > >>% else if (!(dep->de_Attributes & ATTR_DIRECTORY)) > > >>% dep->de_Attributes |= ATTR_ARCHIVE; > > >> > > >>The comment before this says that we ignore attmps to set ATTR_ARCHIVED > > >>for directories. However, it is out of date. WinXP allows setting it > > >>and all the new flags for directories, and so do we. > > > > > >Do you mean we allow setting it in UFS, or where? Obviously the code above > > >won't set it on a directory. > > > > I meant it here. Actually, the comment matches the code -- I somehow missed > > the test in the code. However, the code is wrong. All directories except > > the root directory have this and other attributes, but FreeBSD refuses to > > set them. More below. > > > > >>The WinXP attrib command (at least on a FAT32 fs) doesn't allow setting > > >>or clearing ARCHIVE (even if it is already set or clear) if any of > > >>HIDDEN, READONLY or SYSTEM is already set and remains set after the > > >>command. Thus the HRS attributes act a bit like immutable flags, but > > >>subtly differently. (ffs has the quite different and worse behaviour > > >>of allowing chflags() irrespective of immutable flags being set before > > >>or after, provided there is enough privilege to change the immutable > > >>flags.) Anyway, they should all give some aspects of immutability. > > > > > >We could do that for msdosfs, but why add more things for the user to trip > > >over given how the filesystem is typically used? Most people probably > > >use it for USB thumb drives these days. Or perahps on a dual boot system > > >to access their Windows partition. > > > > The small data drives won't have many files with attributes (except > > ARCHIVE). For multiple-boot, I think the permssions shouldn't be too > > much different than the foreign OS's. I used not to worry about this > > and liked deleting WinXP files without asking it, but recently I spent > > a lot of time recovering a WinXP ntfs partition and changed a bit too > > much using FreeBSD and Cygwin because I didn't understand the > > permissions (especially ACLs). ntfs in FreeBSD was less than r/o so it > > couldn't even back up the permissions (for file flags, it returned the > > garbage in its internal inode flags without translation...). > > > > >*** src/bin/chflags/chflags.1.orig > > >--- src/bin/chflags/chflags.1 > > >*************** > > >*** 101,120 **** > > > .Bl -tag -offset indent -width ".Cm opaque" > > > .It Cm arch , archived > > > set the archived flag (super-user only) > > > .It Cm opaque > > > set the opaque flag (owner or super-user only) > > >- .It Cm nodump > > >- set the nodump flag (owner or super-user only) > > > .It Cm sappnd , sappend > > > > The opaque flag is UF_ too. > > Yes, but all of the flag descriptions are sorted in alphabetical order. > How would you suggest sorting them instead? (SF first and then UF, both in > some version of alphabetical order?) > > > >+ .It Cm snapshot > > >+ set the snapshot flag (most filesystems do not allow changing this flag) > > > > I think none do. It can only be displayed. > > Fixed. > > > chflags(1) doesn't display flags, so this shouldn't be here. The problem > > is that this man page is the only place where the flag names are documented. > > ls(1) and strtofflags(3) just point to here. strtofflags(3) says that the > > flag names are documented here, but ls(1) just has an Xref to here. > > I fixed ls(1) at least. > > > >*** src/lib/libc/sys/chflags.2.orig > > >--- src/lib/libc/sys/chflags.2 > > >--- 71,127 ---- > > > the following values > > > .Pp > > > .Bl -tag -width ".Dv SF_IMMUTABLE" -compact -offset indent > > >! .It Dv SF_APPEND > > > The file may only be appended to. > > > .It Dv SF_ARCHIVED > > >! The file has been archived. > > >! This flag means the opposite of the Windows and CIFS > > >FILE_ATTRIBUTE_ARCHIVE > > > > DOS, Windows and CIFS... > > Fixed. > > > >! attribute. > > >! That attribute means that the file should be archived, whereas > > >! .Dv SF_ARCHIVED > > >! means that the file has been archived. > > >! Filesystems in FreeBSD may or may not have special handling for this > > >flag. > > >! For instance, ZFS tracks changes to files and will clear this bit when a > > >! file is updated. > > > > Does zfs clear it in other circumstances? WinXP doesn't for msdosfs (or > > ntfs?), but FreeBSD clears it when changing some attributes, even for > > null changes (these are: times except for atimes, and the HIDDEN attribute > > when it is changed by chmod() -- even for null changes --, but not for > > the HIDDEN attribute when it is changed (or preserved) by chflags() in > > your new code). I want to to be cleared for metadata so that backup > > utilities can trust the ARCHIVE flag for metadata changes. > > Well, it does look like changing a file or touching it causes the archive > flag to get set with ZFS: > > # touch foo > # ls -lao foo > -rw-r--r-- 1 root wheel uarch 0 Apr 8 21:45 foo > # chflags 0 foo > # ls -lao foo > -rw-r--r-- 1 root wheel - 0 Apr 8 21:45 foo > # echo "hello" >> foo > # ls -lao foo > -rw-r--r-- 1 root wheel uarch 6 Apr 8 21:46 foo > # chflags 0 foo > # ls -lao foo > -rw-r--r-- 1 root wheel - 6 Apr 8 21:46 foo > # touch foo > # ls -lao foo > -rw-r--r-- 1 root wheel uarch 6 Apr 8 21:46 foo > > > >+ .It Dv UF_IMMUTABLE > > >+ The file may not be changed. > > >+ Filesystems may use this flag to maintain compatibility with the Windows > > >and > > >+ CIFS FILE_ATTRIBUTE_READONLY attribute. > > > > So READONLY is only mapped to UFS_IMMUTABLE if it gives immutability? > > No, it's mapped to whatever the CIFS server decides. In my changes to > Likewise, I mapped it to UF_IMMUTABLE. I mapped UF_IMMUTABLE to the ZFS > READONLY flag. As Pawel pointed out, there has been some talk on the > Illumos developers list about just storing the READONLY bit and not > enforcing it in ZFS: > > http://www.listbox.com/member/archive/182179/2013/03/sort/time_rev/page/2/?search_for=readonly > > That complicates things somewhat in the Illumos CIFS server, and so I think > it's a reasonable thing to just record the bit and let the CIFS server > enforce things where it needs to. > > UFS does honor the UF_IMMUTABLE flag, so it may be that we need to create > a UF_READONLY flag that corresponds to the DOS readonly flag and is only > stored, and the enforcement would happen in the CIFS server. > > > >*** src/sys/fs/msdosfs/msdosfs_vnops.c.orig > > >--- src/sys/fs/msdosfs/msdosfs_vnops.c > > >*************** > > >*** 415,431 **** > > > * set ATTR_ARCHIVE for directories `cp -pr' from a more > > > * sensible filesystem attempts it a lot. > > > */ > > >! if (vap->va_flags & SF_SETTABLE) { > > > error = priv_check_cred(cred, PRIV_VFS_SYSFLAGS, 0); > > > if (error) > > > return (error); > > > } > > >! if (vap->va_flags & ~SF_ARCHIVED) > > > return EOPNOTSUPP; > > > if (vap->va_flags & SF_ARCHIVED) > > > dep->de_Attributes &= ~ATTR_ARCHIVE; > > > else if (!(dep->de_Attributes & ATTR_DIRECTORY)) > > > dep->de_Attributes |= ATTR_ARCHIVE; > > > dep->de_flag |= DE_MODIFIED; > > > } > > > > > >--- 424,448 ---- > > > * set ATTR_ARCHIVE for directories `cp -pr' from a more > > > * sensible filesystem attempts it a lot. > > > */ > > >! if (vap->va_flags & (SF_SETTABLE & ~(SF_ARCHIVED))) { > > > > Excessive parentheses. > > Fixed, by moving to UF_ARCHIVE. > > > > error = priv_check_cred(cred, PRIV_VFS_SYSFLAGS, 0); > > > if (error) > > > return (error); > > > } > > > > VADMIN is still needed, and that is too strict. This is a general problem > > and should be fixed separately. > > I took out the check, since I changed the code to use UF_ARCHIVE instead of > SF_ARCHIVED. > > > >! if (vap->va_flags & ~(SF_ARCHIVED | UF_HIDDEN | UF_SYSTEM)) > > > return EOPNOTSUPP; > > > if (vap->va_flags & SF_ARCHIVED) > > > dep->de_Attributes &= ~ATTR_ARCHIVE; > > > else if (!(dep->de_Attributes & ATTR_DIRECTORY)) > > > dep->de_Attributes |= ATTR_ARCHIVE; > > >+ if (vap->va_flags & UF_HIDDEN) > > >+ dep->de_Attributes |= ATTR_HIDDEN; > > >+ else > > >+ dep->de_Attributes &= ~ATTR_HIDDEN; > > >+ if (vap->va_flags & UF_SYSTEM) > > >+ dep->de_Attributes |= ATTR_SYSTEM; > > >+ else > > >+ dep->de_Attributes &= ~ATTR_SYSTEM; > > > dep->de_flag |= DE_MODIFIED; > > > } > > > > Technical old and new problems with msdosfs: > > - all directories except the root directory support the 3 attributes > > handled above, and READONLY > > - the special case for the root directory is because before FAT32, the > > root directory didn't have an entry for itself (and was otherwise > > special). With FAT32, the root directory is not so special, but > > still doesn't have an entry for itself. > > - thus the old code in the above is wrong for all directories except > > the root directory > > - thus the new code in the above is wrong for the root directory. It > > will make changes to the in-core denode. These can be seen by stat() > > for a while, but go away when the vnode is recycled. > > - other code is wrong for directories too. deupdat() refuses to > > convert from the in-core denode to the disk directory entry for > > directories. So even when the above changes values for directories, > > the changes only get synced to the disk accidentally when there is > > a large change (such as for extending the directory), to the directory > > entry. > > - being the root directory is best tested for using VV_ROOT. I use the > > following to fix the corresponding bugs in utimes(): > > > > /* Was: silently ignore the non-error or error for all dirs. > > */ > > if (DETOV(dep)->v_vflag & VV_ROOT) > > return (EINVAL); > > /* Otherwise valid. */ > > > > deupdat() needs a similar change to not ignore all directories. > > Okay, I think these issues should now be fixed. We now refuse to change > attributes only on the root directory. And I updatd deupdat() to do the > same. > > When a directory is created or a file is added, the archive bit is not > changed on the directory. Not sure if we need to do that or not. (Simply > changing msdosfs_mkdir() to set ATTR_ARCHIVE was not enough to get the > archive bit set on directory creation.) Bruce, any comment on this? Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-arch@FreeBSD.ORG Fri Apr 19 17:43:52 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C881DFA; Fri, 19 Apr 2013 17:43:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id F0F985EA; Fri, 19 Apr 2013 15:57:28 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 7A1061041552; Fri, 19 Apr 2013 22:53:51 +1000 (EST) Date: Fri, 19 Apr 2013 22:53:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Kenneth D. Merry" Subject: Re: patches to add new stat(2) file flags In-Reply-To: <20130418184951.GA18777@nargothrond.kdm.org> Message-ID: <20130419215624.L1262@besplex.bde.org> References: <20130307000533.GA38950@nargothrond.kdm.org> <20130307222553.P981@besplex.bde.org> <20130308232155.GA47062@nargothrond.kdm.org> <20130310181127.D2309@besplex.bde.org> <20130409190838.GA60733@nargothrond.kdm.org> <20130418184951.GA18777@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=A8I0pNqG c=1 sm=1 a=n2O7wv11oSwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=YOiZBDKP_E4A:10 a=QuKyM733q63FOVycHlwA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: arch@FreeBSD.org, fs@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:43:52 -0000 On Thu, 18 Apr 2013, Kenneth D. Merry wrote: > On Tue, Apr 09, 2013 at 13:08:38 -0600, Kenneth D. Merry wrote: >> ... >> Okay, I think these issues should now be fixed. We now refuse to change >> attributes only on the root directory. And I updatd deupdat() to do the >> same. >> >> When a directory is created or a file is added, the archive bit is not >> changed on the directory. Not sure if we need to do that or not. (Simply >> changing msdosfs_mkdir() to set ATTR_ARCHIVE was not enough to get the >> archive bit set on directory creation.) > > Bruce, any comment on this? I didn't get around to looking at it closely. Just had a quick look at the msdosfs parts. Apparently we are already doing the same as WinXP for ATTR_ARCHIVE on directories. Not the right thing, but: - don't set it on directory creation - don't set it on directory modification - allow setting and clearing it (with your changes). @ *** src/lib/libc/sys/chflags.2.orig @ --- src/lib/libc/sys/chflags.2 @ *************** @ *** 112,137 **** @ ... @ --- 112,170 ---- @ ... @ + .It Dv UF_IMMUTABLE @ + The file may not be changed. @ + Filesystems may use this flag to maintain compatibility with the DOS, Windows @ + and CIFS FILE_ATTRIBUTE_READONLY attribute. msdosfs doesn't use this yet. It uses ATTR_READONLY, and doesn't map this to or from UF_IMMUTABLE. I think I want ATTR_READONLY to be a flag and not affect the file permissions (just like immutable flags normally don't affect the file permissions. Does CIFS FILE_ATTRIBUTE_READONLY have exactly the same semantics as IMMUTABLE? That is, does it prevent all operations on the file and the file's metadata except read()? For IMMUTABLE, the other operations that it disallows include setattr(), rename() and unlink(). Well it doesn't in WinXP using Cygwin. I made a directory with attributes +R, and this didn't prevent creating files in the directory or rmdir of the directory. Even attributes +R +H +S didn't prevent these operations. Maybe +R isn't really used for directories, like +A. Then for a file with +R +H +S: - rm asked before deleting it (+R changed its fake permissions from rw-r--r-- to r--r--r--). - touching it succeeded - attrib on it succeeded - writing it failed. So it seems that in WinXP, ATTR_READONLY is ignored for directories, and more like the !writeable permission than the immutable flag. @ *** src/sys/fs/msdosfs/msdosfs_denode.c.orig @ --- src/sys/fs/msdosfs/msdosfs_denode.c @ *************** @ *** 300,307 **** @ if ((dep->de_flag & DE_MODIFIED) == 0) @ return (0); @ dep->de_flag &= ~DE_MODIFIED; @ ! if (dep->de_Attributes & ATTR_DIRECTORY) @ ! return (0); @ if (dep->de_refcnt <= 0) @ return (0); @ error = readde(dep, &bp, &dirp); @ --- 300,309 ---- @ if ((dep->de_flag & DE_MODIFIED) == 0) @ return (0); @ dep->de_flag &= ~DE_MODIFIED; @ ! /* Was: silently ignore attribute changes for all dirs. */ @ ! if (DETOV(dep)->v_vflag & VV_ROOT) @ ! return (EINVAL); @ ! /* Otherwise valid. */ Clean up the comments a bit. Say nothing, or that all attributes apply to all directories except the root directory. Perhaps the VV_ROOT case is unreachable because callers filter out this case. I have a debugger trap for it. @ if (dep->de_refcnt <= 0) @ return (0); @ error = readde(dep, &bp, &dirp); @ *** src/sys/fs/msdosfs/msdosfs_vnops.c.orig @ --- src/sys/fs/msdosfs/msdosfs_vnops.c @ *************** @ *** 398,403 **** @ --- 402,418 ---- @ if (vap->va_flags != VNOVAL) { @ if (vp->v_mount->mnt_flag & MNT_RDONLY) @ return (EROFS); @ + /* @ + * We don't allow setting attributes on the root directory, @ + * because according to Bruce Evans: "The special case for @ + * the root directory is because before FAT32, the root @ + * directory didn't have an entry for itself (and was @ + * otherwise special). With FAT32, the root directory is @ + * not so special, but still doesn't have an entry for itself." @ + */ @ + if (vp->v_vflag & VV_ROOT) @ + return (EINVAL); @ + @ if (cred->cr_uid != pmp->pm_uid) { @ error = priv_check_cred(cred, PRIV_VFS_ADMIN, 0); @ if (error) No need to give the source. I prefer the do this check after the permissions check, but if it is done early then it is best done as a single check for all attributes in msdosfs_settattr() and not just for flags. Currently there is: - no check for ownerships. We only allow null changes to ownerships. With no check like the above, we allow them even for the root directory, while the above disallows null changes to flags for the root directory. - for truncate(), the error is EISDIR for all directories. - for file times, we silently ignore changes for all directories, after doing permissions checks. Only the root directory should be special. - for file permissions, we handle directories as for file times. Now the only possible non-null change is of ATTR_READONLY, and since this apparently has no effect in WinXP, ignorig changing it for directories is best. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Apr 20 06:17:52 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 56ADACDF; Sat, 20 Apr 2013 06:17:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 25B23FDF; Sat, 20 Apr 2013 06:17:52 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id at1so1876241iec.15 for ; Fri, 19 Apr 2013 23:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=lQuaF3VXwvFpnUxjQboljE/FPXqKsFHj54VyNyxlu9c=; b=aaktUWa6cE40Ri1m5cU2YoRat3w37bvDBHuYC/npwCkC+DzokOmV3bJr1PXNftu7vs bG/UUUyV026SM0Z4Hjyeul6eFUvaFd8q1SQX53vvuAq2gNn1NCviZadoPaLrdEWgrpCZ 6b7c7INGGnyR+ap7yPdA3jXGo79CTwYiPSV4uXKXEMB+rJ3gixuaJv23IkvM1EDW7nxJ hnC2aBbHt1YNVYqUOfMglJsTg7ICMKtI3MUmMBut1cXeOScss/huB74xH4VAxbDIFUnY YgDr1/RuGJxGhi+BlAch2VfdJTJj0arjFoqq2Iuyoal0YaP4f9w7291lkDkghIBkkWkF yz8Q== MIME-Version: 1.0 X-Received: by 10.50.197.170 with SMTP id iv10mr16898928igc.62.1366438670372; Fri, 19 Apr 2013 23:17:50 -0700 (PDT) Received: by 10.64.86.70 with HTTP; Fri, 19 Apr 2013 23:17:50 -0700 (PDT) Date: Fri, 19 Apr 2013 23:17:50 -0700 Message-ID: Subject: [RFC] [Optionally] build tests with buildworld From: Garrett Cooper To: arch@FreeBSD.org, toolchain@FreeBSD.org Content-Type: multipart/mixed; boundary=bcaec5396b508e130904dac4cb6c Cc: "Simon J. Gerraty" , Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 06:17:52 -0000 --bcaec5396b508e130904dac4cb6c Content-Type: text/plain; charset=ISO-8859-1 Hi arch@ and toolchain@, One of the items that I'm proposing be added to Makefile.inc1 in order to make building and installing tests on CURRENT (ATF and otherwise) is a build knob called TESTS_WITH_WORLD (the name can be modified), which allows me to build and install various tests on my git branch like the example ATF tests I produced, pjdfstest, some of the prove tests from tools/regression, etc (there are other outstanding changes, but this was the key one that I need feedback on just to be safe). The effective change is attached (Gmail will no doubt mangle it, so please let me know if you want another copy). I made the change to Makefile.inc1 in order to ensure that the change was self-contained and because it was the simplest, cleanest way to do things without introducing a lot of unwanted complexity. I'm asking for feedback on the following items: 1. Does the change make functional sense? If not, why? 2. Do the semantics (variable names, whether or not they're defined) need to be modified to match MK_* semantics or be made more consistent in any particular way? If so, why? 3. Will anyone have serious heartburn (already have a similar change implemented, think it's done in a backwards manner) if this change is implemented? If so, why? Thanks! -Garrett PS Please CC me on all replies as I'm not subscribed to the list. --bcaec5396b508e130904dac4cb6c Content-Type: application/octet-stream; name="TESTS_WITH_WORLD.patch" Content-Disposition: attachment; filename="TESTS_WITH_WORLD.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hfqea49r0 SW5kZXg6IE1ha2VmaWxlLmluYzEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTWFrZWZpbGUuaW5jMQkocmV2aXNp b24gMjQ5NjY1KQorKysgTWFrZWZpbGUuaW5jMQkod29ya2luZyBjb3B5KQpAQCAtOTEsNiArOTEs MTEgQEAKIC5pZiAke01LX09GRUR9ICE9ICJubyIKIFNVQkRJUis9Y29udHJpYi9vZmVkCiAuZW5k aWYKKy5pZiBkZWZpbmVkKC5QQVJTRURJUikgIyBic2QudGVzdC5tayBkb2Vzbid0IHdvcmsgd2l0 aCAhYm1ha2UKKy5pZiBkZWZpbmVkKFRFU1RTX1dJVEhfV09STEQpCitTVUJESVIrPXRlc3RzCisu ZW5kaWYKKy5lbmRpZgogIwogIyBXZSBtdXN0IGRvIGV0Yy8gbGFzdCBmb3IgaW5zdGFsbC9kaXN0 cmlidXRlIHRvIHdvcmsuCiAjCkBAIC0yNzcsNiArMjgyLDEzIEBACiAJCVZFUlNJT049IiR7VkVS U0lPTn0iIFwKIAkJSU5TVEFMTD0ic2ggJHsuQ1VSRElSfS90b29scy9pbnN0YWxsLnNoIiBcCiAJ CVBBVEg9JHtUTVBQQVRIfQorCisjIG1ha2UgaGllcmFyY2h5CitITUFLRT0JCSR7TUFLRX0gTE9D QUxfTVRSRUU9JHtMT0NBTF9NVFJFRX0KKy5pZiBkZWZpbmVkKE5PX1JPT1QpCitITUFLRSs9CQlN RVRBTE9HPSR7TUVUQUxPR30gLUROT19ST09UCisuZW5kaWYKKwogLmlmICR7TUtfQ0RETH0gPT0g Im5vIgogV01BS0VFTlYrPQlOT19DVEY9MQogLmVuZGlmCkBAIC0zNzgsNiArMzkwLDE0IEBACiBJ TUFLRV9NVFJFRT0JTVRSRUVfQ01EPSJubXRyZWUgJHtNVFJFRUZMQUdTfSIKIC5lbmRpZgogCisu aWYgZGVmaW5lZCguUEFSU0VESVIpICMgYnNkLnRlc3QubWsgZG9lc24ndCB3b3JrIHdpdGggIWJt YWtlCisuaWYgZGVmaW5lZChURVNUU19XSVRIX1dPUkxEKSAmJiAhZGVmaW5lZChOT19URVNUUykK K0hNQUtFKz0JCS1EV0lUSF9URVNUUworSU1BS0UrPQkJLURXSVRIX1RFU1RTCitXTUFLRSs9CQkt RFdJVEhfVEVTVFMKKy5lbmRpZgorLmVuZGlmCisKICMga2VybmVsIHN0YWdlCiBLTUFLRUVOVj0J JHtXTUFLRUVOVn0KIEtNQUtFPQkJJHtLTUFLRUVOVn0gJHtNQUtFfSAkey5NQUtFRkxBR1N9ICR7 S0VSTkVMX0ZMQUdTfSBLRVJORUw9JHtJTlNUS0VSTk5BTUV9CkBAIC00ODgsOCArNTA4LDkgQEAK IAlAZWNobyAiPj4+IHN0YWdlIDQuMjogYnVpbGRpbmcgbGlicmFyaWVzIgogCUBlY2hvICItLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSIKIAkke18rX31jZCAkey5DVVJESVJ9OyBcCi0JICAgICR7V01BS0V9IC1ETk9fRlNDSEcgLURX SVRIT1VUX0hUTUwgLURXSVRIT1VUX0lORk8gLUROT19MSU5UIFwKLQkgICAgLURXSVRIT1VUX01B TiAtRE5PX1BST0ZJTEUgbGlicmFyaWVzCisJICAgICR7V01BS0U6Ti1EV0lUSF9URVNUU30gXAor CSAgICAtRE5PX0ZTQ0hHIC1EV0lUSE9VVF9IVE1MIC1EV0lUSE9VVF9JTkZPIC1ETk9fTElOVCBc CisJICAgIC1EV0lUSE9VVF9NQU4gLUROT19QUk9GSUxFIC1ETk9fVEVTVFMgbGlicmFyaWVzCiBf ZGVwZW5kOgogCUBlY2hvCiAJQGVjaG8gIi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIgpAQCAtMTMyMCwxMiArMTM0MSw3IEBACiAj IGhpZXJhcmNoeSAtIGVuc3VyZSB0aGF0IGFsbCB0aGUgbmVlZGVkIGRpcmVjdG9yaWVzIGFyZSBw cmVzZW50CiAjCiBoaWVyYXJjaHkgaGllcjoKLS5pZiBkZWZpbmVkKE5PX1JPT1QpCi0JY2QgJHsu Q1VSRElSfS9ldGM7ICR7TUFLRX0gTE9DQUxfTVRSRUU9JHtMT0NBTF9NVFJFRX0gXAotCSAgICAt RE5PX1JPT1QgTUVUQUxPRz0ke01FVEFMT0d9IGRpc3RyaWItZGlycwotLmVsc2UKLQljZCAkey5D VVJESVJ9L2V0YzsgJHtNQUtFfSBMT0NBTF9NVFJFRT0ke0xPQ0FMX01UUkVFfSBkaXN0cmliLWRp cnMKLS5lbmRpZgorCWNkICR7LkNVUkRJUn0vZXRjICYmICR7SE1BS0V9IGRpc3RyaWItZGlycwog CiAjCiAjIGxpYnJhcmllcyAtIGJ1aWxkIGFsbCBsaWJyYXJpZXMsIGFuZCBpbnN0YWxsIHRoZW0g dW5kZXIgJHtERVNURElSfS4K --bcaec5396b508e130904dac4cb6c--