On 5/17/19 1:18 PM, h...@zytor.com wrote:
>
> Ok... I just realized this does not work for a modular initramfs, composed at
> load time from multiple files, which is a very real problem. Should be easy
> enough to deal with: instead of one large file, use one companion file per
> source file, perhaps something like filename..xattrs (suggesting double dots
> to make it less likely to conflict with a "real" file.) No leading dot, as it
> makes it more likely that archivers will sort them before the file proper.
>
> A side benefit is that the format can be simpler as there is no need to
> encode the filename.
>
> A technically cleaner solution still, but which would need archiver
> modifications, would be to encode the xattrs as an optionally nameless file
> (just an empty string) with a new file mode value, immediately following the
> original file. The advantage there is that the archiver itself could support
> xattrs and other extended metadata (which has been requested elsewhere); the
> disadvantage obviously is that that it requires new support in the archiver.
> However, at least it ought to be simpler since it is still a higher protocol
> level than the cpio archive itself.
>
> There's already one special case in cpio, which is the "!!!TRAILER!!!"
> filename; although I don't think it is part of the formal spec, to the extent
> there is one, I would expect that in practice it is always encoded with a
> mode of 0, which incidentally could be used to unbreak the case where such a
> filename actually exists. So one way to support such extended metadata would
> be to set mode to 0 and use the filename to encode the type of metadata. I
> wonder how existing GNU or BSD cpio (the BSD one is better maintained these
> days) would deal with reading such a file; it would at least not be a
> regression if it just read it still, possibly with warnings. It could also be
> possible to use bits 17:16 in the mode, which are traditionally always zero
> (mode_t being 16 bits), but I believe are present in most or all of the cpio
> formats for historical reasons. It might be accepted better by existing
> implementations to use one of these high bits combined with S_IFREG, I dont
> know.
>
Correction: it's just !!!TRAILER!!!.
I tested with GNU cpio, BSD cpio, scpio and pax.
With a mode of 0:
- GNU cpio errors, but extracts all the other files.
- BSD cpio extracts them as regular files.
- scpio and pax abort.
With a mode of 0x18000 (bit 16 + S_IFREG), all of them happily extracted
the data as regular files.
-hpa
