public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Marangi <ansuelsmth@gmail.com>
To: David Disseldorp <ddiss@suse.de>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier <nsc@kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH] initramfs: correctly handle space in path on cpio list generation
Date: Sun, 15 Feb 2026 03:54:54 +0100	[thread overview]
Message-ID: <69913581.5d0a0220.340e.3d3e@mx.google.com> (raw)
In-Reply-To: <20260211134025.57a4d249.ddiss@suse.de>

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

      reply	other threads:[~2026-02-15  2:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260209153800.28228-1-ansuelsmth@gmail.com>
2026-02-10 11:34 ` [RFC PATCH] initramfs: correctly handle space in path on cpio list generation David Disseldorp
2026-02-10 17:37   ` Christian Marangi
2026-02-11  0:43     ` David Disseldorp
2026-02-11  0:58       ` Christian Marangi
2026-02-11  2:40         ` David Disseldorp
2026-02-15  2:54           ` Christian Marangi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69913581.5d0a0220.340e.3d3e@mx.google.com \
    --to=ansuelsmth@gmail.com \
    --cc=0x7f454c46@gmail.com \
    --cc=ddiss@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox