From owner-freebsd-fs@FreeBSD.ORG Mon Aug 26 18:00:06 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EE33D396 for ; Mon, 26 Aug 2013 18:00:05 +0000 (UTC) (envelope-from slivnik@tomaz.name) Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) by mx1.freebsd.org (Postfix) with ESMTP id CB3DE2487 for ; Mon, 26 Aug 2013 18:00:05 +0000 (UTC) Received: from [10.0.1.162] ([212.159.115.195]) by p3plsmtpa09-09.prod.phx3.secureserver.net with id HVyR1m00i4D1Akc01VyTep; Mon, 26 Aug 2013 10:58:29 -0700 From: =?windows-1252?Q?=22Dr_Slivnik_Toma=9E_MA_=28Cantab=29_MMath_=28?= =?windows-1252?Q?Cantab=29_PhD_=28Cantab=29_FTICA=22?= Subject: extattr(2) Date: Mon, 26 Aug 2013 18:58:24 +0100 Message-Id: <02F402A6-8E33-4504-8634-1362EF8C75AF@tomaz.name> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 18:00:06 -0000 I posted this on FreeBSD forums = (http://forums.freebsd.org/showthread.php?t=3D41552) and was advised by = the moderator that this mailing list may be the right forum. ------------------------------------------------- There seems to me to be a race condition in the design of the extattr(2) = interface. I can't imagine I am the first person to notice this, but I = have not been able to find any discussion of it, so I mention it. To read an attribute, I have to first call len =3D extattr_get_file = (path, attrnamespace, attrname, NULL, 0) to obtain its length, then call = extattr_get_file (path, attrnamespace, attrname, buf, len) to read it. = If the attribute changes between the two calls to a longer value, I will = read data which is in an inconsistent state, and not be aware of it. One way to work around it would be to always call extattr_get_file = (path, attrnamespace, attrname, buf, len+1) and repeat if = length-extension is detected, but it seems like a clunky way of doing = it. The issue could easily be resolved in one of many ways, by some locking = or snapshotting mechanism, e.g. by adding a call like this to the = interface: Code: int extattr_snapshot_and_getlen_file (const char *path, int = attrnamespace, const char *attrname); A subsequent read of the attribute would release the snapshot. Existing = code would not be affected.=