lkml.org 
[lkml]   [2007]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Versioning file system
On Tue, 19 Jun 2007, Jörn Engel wrote:

> On Mon, 18 June 2007 18:10:21 -0400, Theodore Tso wrote:
>> On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
>>> And that makes them different from extended attributes, how?
>>>
>>> Both of these really are nothing but ad hocky syntactic sugar for
>>> directories, sometimes combined with in-filesystem support for small
>>> data items.
>>
>> There's a good discussion of the issues involved in my LCA 2006
>> presentation.... which doesn't seem to be on the LCA 2006 site. Hrm.
>> I'll have to ask that this be fixed. In any case, here it is:
>>
>> http://thunk.org/tytso/forkdepot.odp
>
> The main difference appears to be the potential size. Both extended
> attributes and forks allow for extra data that I neither want or need.
> But once the extra space is large enough to hide a rootkit in, it
> becomes a security problem instead of just something pointless.
>
> Pointless here means that _I_ don't see the point. Maybe there are
> valid uses for extended attributes. If there are, noone has explained
> them to me yet.

Most of the extended attribute systems I have seen have been a set of
flags. "If this bit is set, the user can do thus to this object."
Sometimes it is a named attribute that is attached to the object.

Forks tend to be "this blob of data is attached to this object".

With forks, the choices tend to be a lot more arbitrary.

--
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
- Alan Cox
\
 
 \ /
  Last update: 2007-06-19 00:59    [W:0.047 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site