Monday, April 16, 2007

EA handling change

The way xar handles extended attributes has been rewritten today. This will likely introduce some bugs, and breaks (at least for now) EA extraction on old archives.
Before, xar would represent EAs as:
<ea>
    <user.foo>
        ...
    </user.foo>
    <user.bar>
        ...
    </user.bar>
</ea>

However, XML has a limited characterset that can be represented in those <keys>. So, clearly this will not work for EAs with non-UTF8 characters, or EAS containing characters reserved in xml, such as <

To solve this, EA representation has changed to:
<ea>
    <name>user.foo</name>
    ...
</ea>
<ea>
    <name>user.bar</name>
    ...
</ea>

This allows us to handle the case of reserved characters and non-UTF8 characters the same way we handle them for filenames. However, xar used a path based reference system for properties in the past. So, the string "ea/user.foo" would identify the property that contained all the information about EA user.foo. Additionally, the root level identifier for properties has become non-unique. So, internally xar needed to reference the actual data structure representing the EA instead of just the path to the EA. This change affected almost every source file in libxar. However, this was a pretty glaring bug, and should make xar's EAs actually useful now.

1 comment:

perd said...

zomg! sechzy! this will revolutionize OD^WDarw^WMac OS X!