[Unison-hackers] Unison and extended attributes (xattr) on Tiger?

[Alan Schmitt]

On 23 juin 06, at 15:25, Benjamin Pierce wrote:

> This is something we've dealt with already for some somewhat similar
> cases -- e.g., the TYPE and CREATOR fields on OSX, which I believe
> are handled fairly cleanly, and resource forks, which we didn't
> succeed in handling at especially cleanly (the possible presence of
> resource forks pollutes a lot of code in a lot of modules).  So
> there's a good and a bad precedent.  :-)

Interesting.

> For the UI, I guess the main issue is how big the information is --
> can it just go in the same place as the permission bits, or does it
> need to be summarized in some way?

What if permission bits are changed in one direction, and file  
content in the other direction: is this a conflict? How does the UI  
may reflect this?

The problem is that different extended attributes may be changed on  
both side, and I don't really see how to nicely present this yet.

Alan

-- 
Alan Schmitt <http://alan.petitepomme.net/>

The hacker: someone who figured things out and made something cool  
happen.
.O.
..O
OOO


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20060623/d40032db/PGP.pgp