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>
index | next in thread | raw e-mail
I posted this on FreeBSD forums (http://forums.freebsd.org/showthread.php?t=41552) 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 = 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02F402A6-8E33-4504-8634-1362EF8C75AF>