Date: Mon, 26 Aug 2013 18:58:24 +0100 From: =?windows-1252?Q?=22Dr_Slivnik_Toma=9E_MA_=28Cantab=29_MMath_=28?= =?windows-1252?Q?Cantab=29_PhD_=28Cantab=29_FTICA=22?= <slivnik@tomaz.name> To: freebsd-fs@freebsd.org Subject: extattr(2) Message-ID: <02F402A6-8E33-4504-8634-1362EF8C75AF@tomaz.name>
next in thread | raw e-mail | index | archive | help
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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02F402A6-8E33-4504-8634-1362EF8C75AF>