Re: [RFC PATCH] initramfs: correctly handle space in path on cpio list generation

From: Christian Marangi

Date: Sat Feb 14 2026 - 21:55:50 EST


On Wed, Feb 11, 2026 at 01:40:25PM +1100, David Disseldorp wrote:
> On Wed, 11 Feb 2026 01:58:27 +0100, Christian Marangi wrote:
>
> > > What happens when someone wants support for filenames containing spaces
> > > and quotes?
> > >
> >
> > I mean... it's a less common case where filename start to have almost invalid
> > char but yes it's a valid point.
> >
> > > > I'm open to both solution. Lets just agree on one of the 2.
> > >
> > > I don't think any of the options will be particularly simple, but
> > > nul-byte delimited field support might be the most straightforward.
> > >
> >
> > Yes that was the initial idea but was quickly scrapped as major work is needed
> > in the .c tool to handle NULL separated entry.
> >
> > Can you by chance point to me how the GNU tool work with --null ?
> >
> >
> > They also create a cpio_list file with entry NULL separated?
>
> E.g. dracut uses the GNU cpio --null alongside find -print0:
>
> cd "$initdir"
> find . -print0 | sort -z \
> | cpio ${CPIO_REPRODUCIBLE:+--reproducible} --null ${cpio_owner:+-R "$cpio_owner"} -H newc -o --quiet \
> | $compress >> "${DRACUT_TMPDIR}/initramfs.img"

Ok I finished developing this and while testing it I had an interesting idea...
What if the delimiter is auto detected by checking the very next char after the
file type?

This way we can support a number of different format without having to update
any file...

The .c file had to be reworked for the tokenizer conversion so this
autodetection feature is litterally disabling the format validation of the
string and make the delimiter dynamic for the string based on the next char


For example in one file we can have these kind of thing without having to
support any additional arg.

nod /dev/tty0 660 0 0 c 4 0
nod /dev/tty1 660 0 0 c 4 1
nod /dev/random 666 0 0 c 1 8
nod /dev/urandom 666 0 0 c 1 9
# dir /dev/pts 755 0 0

nod|/dev/pts|755|0|0|c|0|9

dir\0/bin\755\01000\01000

(the \0 are NULL char, it's here to display in the actual file they are zero
char)

Wonder if this might be interesting or I should just stick to the current idea
of adding a -0 option and enforce the NULL delimiter.



--
Ansuel