OS/2, eCS & ArcaOS - Technical > Programming

gcc - building libarchive

<< < (3/3)

Jochen Schäfer:
I looked into that. But the xattr interface doesn't fit to the way OS/2's EA work.

Dave Yeo:
Seems just need a translation interface with OS/2 EA's being of type user, and ignoring ACL's for now.
Pretty sure if booted to Linux, a mounted JFS partition would allow xttrs to manipulate the OS/2 EA's. They're of key:value everywhere by the looks of it.
Might also want to filter out the libc stuff or put in system

Jochen Schäfer:
The problem is: OS/2 zip ports just uses the memory layout of OS/2's EA api in the extension space (don't know the correct terminology) of a file stored in the zip. It also uses a OS/2 specific ID for it. Paul can correct me, if I got that wrong.
That means the XAttr stores the EA in a completely different layout as OS/2 zips do. You can go this route, but it seems to me, it will be completely incompatible to our established archiving programs.
BTW, I was beginning to write a xattr interface for libc, but the sheer amount of infrastructure needed to cope with OS/2 all in one place file oriented approach in a item oriented api, gave me headaches and made me drop it for the moment.
Also, there is the issue of different EA types, like icons etc. xattr only deals with memory blobs, it has no way to treat application defined EA, which might be essential for the functioning of an application, correctly without annotating the xattr attributes, which again will break compatibility.

If you want to do the xattr approach, go for it. I don't know, if it is worth it.
It seems to me far easier to copy the Windows approach and extend libarchive that way.

Navigation

[0] Message Index

[*] Previous page

Go to full version