duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Tar replacement - format proposal


From: Will Dyson
Subject: Re: [Duplicity-talk] Tar replacement - format proposal
Date: Fri, 26 Sep 2003 18:40:04 -0400

On Fri, 2003-09-26 at 16:35, Will Dyson wrote:

> I've written a filesystem driver for the Linux kernel (befs), although I

Thinking about befs made me realize there is one important thing missing
from the proposal: Extended attributes.

Most extended attributes will be small and textual, and can be archived
in the file index entry without trouble. However, nothing in the
extended attribute interface mandates that attributes be small or
textual. Some filesystems (such as befs, ntfs, and probably the upcoming
reiser4 filesystem) efficiently support extended attributes that are
arbitrarily large.

In fact, under BeOS, it is common to attach an image file's thumbnail as
an extended attribute.

The zip archive format supports extended attributes, but only allows 64k
of attributes per file. This limit is not easy to hit for most users,
but it can be done. Since we are designing for the future, we should not
have any such limit.

Taking a page from the design of befs, I propose that the default way of
dealing with an extended attribute is to store it along with the regular
file data and put a pointer to it in the file index record. Then, as an
optimization, we can store attributes who's value is both small and
text-only directly in the file index record.

-- 
Will Dyson
"Back off man, I'm a scientist!" -Dr. Peter Venkman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]