From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46CA078F.8000403@gmail.com> Date: Mon, 20 Aug 2007 17:28:47 -0400 From: Robert William Fuller User-Agent: Thunderbird 1.5.0.10 (X11/20070515) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Re: everything is a directory References: <20070820195340.945DAC69DC@mail.cse.psu.edu> In-Reply-To: <20070820195340.945DAC69DC@mail.cse.psu.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: ae35fcda-ead2-11e9-9d60-3106f5b1d025 Dave Eckhardt wrote: >> In XFS, several tools use EA's to assign attributes like "DO NOT >> DUMP" or hierarchical file management data. This data *should* be >> discarded by normal tools (since cp is creating a new file, and mv >> only modifes directories but not i-node's EAs) and are of interest >> only to those system daemons > > Some attributes (icon) "*should*" be copied. > > Other attributes (don't back me up) "*should* be discarded". > > New attributes will doubtless be added every week. > > How's a tool to know the right way to treat each attribute? The answer to that seems obvious. A single bit could determine whether or not an attribute is transient or more permanent. Having worked on various data replication and backup products, I have observed real problems copying data from one type of file system to another because not every file system supports the same attributes or the same characters in filenames. Extended attributes seem like a convenient place to stuff such data, but the fact that not all file systems support extended attributes poses another problem, unless you chose to ignore all file systems that do not support extended attributes. Having said that, I have to say that I'm not a fan of extended attributes, for a couple of reasons. First, they lack visibility. I suppose that to some extent, this is merely a problem of interfaces, both user interfaces and programming interfaces. Second, they require tools to handle two types of attributes, those "built-in" to the file system, as well as those stored in extended attributes. Again, this is probably merely a matter of interface. There is no reason the same interface could not be used to enumerate both built-in and extended attributes. Perhaps my objections to extended attributes are all addressable? Still, I have to wonder if there isn't a better solution. Finally, to argue that files are not objects seems silly. They ARE objects. They have properties. They have well defined interfaces for manipulating those properties. A more reasonable argument may be that they are not object oriented since they lack certain prerequisites such as inheritance and abstraction, both mechanisms of extensibility. What a way to introduce myself to the list. I'm sure I'm making friends fast :-p