[Top][All Lists]

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

Re: [Gnu-arch-users] Re: arch with 'special files'

From: Ulf Ochsenfahrt
Subject: Re: [Gnu-arch-users] Re: arch with 'special files'
Date: Mon, 04 Apr 2005 09:08:07 +0200

On Sun, 2005-04-03 at 13:35 +0200, address@hidden wrote:
> Well... yes and no. Tla (any system archiving --hm... let's call it files--
> tries to be file-system agnostic. Then one's `native´ metadata becomes
> other's `alien´ metadata. See for example Unix permissions on DOS. Or
> HTs EAs on ext2. Or the file attributes you mentioned on VFAT. Or one
> of Macs funny forks. And it goes on. Why shouldn't one of Archs applications
> define its own thingie it wants attached to some files (like, as has already
> come up here: ``this file is an MSDOS text file and I want it be CRLF
> whenever checked out on MSDOS and just LF when checked out on UNIX´´.
> Or whatever.
> The question being thrown back and forth here is: should Arch support this?
> Does it make sense? If yes: at what level? Should it special-case some
> ``important´´ instances, like permissions (and maybe ownerships) and leave
> the rest to users?

tla should support different os specific metadata storage
implementations, in particular linux xattr and MacOS whateveritscalled
(MacOS also has a metadata thing, doesn't it?) and Windows
somethingsomething (is there a win equiv.?). It should also have a user
interface for querying and setting metadata (so tla-specific scripts can
rely on transparent cross-platform behaviour). In case the filesystem
doesn't support it, tla will have to fallback onto a file-based storage.

tla really should integrate with platform-specific tools.

One piece of metadata would be the id, another would be line-ending
behaviour (something like force-lf, force-crlf, error-crlf, ...), with
no setting implying standard behaviour (do nothing).

I guess the keys for these should all start with x-gnuarch- or gnuarch-
to avoid name conflicts.


-- Ulf

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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