Date: Tue, 7 Dec 1999 02:12:54 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-arch@freebsd.org Subject: Extended Attributes: a few more calls and more details Message-ID: <Pine.BSF.3.96.991207020414.14113G-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
It became clear in #bsdcode discussion that the interface I recommended didn't provide all of the bootstrapping information people needed to understand my intent. As such, I suggested a couple of vfs calls, similar to quotactl, for initalizing and managing attributes: vfs_extattr_create(mount, name, size, access) This would create a new attribute of fixed size size in the specified file system. Access would be an indicator of who was allowed to modify the values of these attributes--useful values considered so far have been "kernel only" vs. "file owner". Would fail if it already existed, or something nasty went wrong :-). vfs_extattr_delete(mount, name) Delete the specified attribute and recover all space associated with storing that attribute, stripping the values from all files. Only works if it existed :-). To set up a UFS file system for quotas, you'd want to do (hypothetical user command line util): chattr create /usr name="acl_access" size=388 access="kernel" chattr creaet /usr name="acl_default" size=388 access="kernel" And remove the support later: chattr delete /usr name="acl_access" chattr delete /usr name="acl_default" This would be a bad idea while ACLs are active on the fs, however. You can imagine some other useful ones, such as name="mac_label", name="capabilities", name="tripwire_md5", name="dumpstate", name="mime_type", etc. The intent of these attributes would be to provide local system support for fs-oriented features, not to provide a broader-than-flat-file semantic for the file system (such as file forks) for user applications. This would mean "don't put icons here", and "don't make files that contain both HTML and text versions this way". Instead it would be for optimized, consistently-sized per-file/per-directory meta data of a systems nature. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991207020414.14113G-100000>