From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 840801FDE31 for ; Sun, 15 Feb 2026 02:54:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771124100; cv=none; b=ASBt93ZsSvYel014Li4MjRC03olvcT3sYteoiABIqlw/uHtMu/P/nAv1YnNu1jEOvnqGXM+jkbRJwmTijZb+eTRHuBoHDV2mQOYskYofL/WAY/tlCWJyexQuJ6MvfT8WML+66Kq5dhQzX/hi4ntYgqkpX6phWGjhzPDoADczaUA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771124100; c=relaxed/simple; bh=fK7ZZkyiK48dzgBWcXdpx7b+6/1w/6JcjME1eC3IhS8=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VtVQxVxi28fmdE5n9HPD3HTqoIS3wd2G7UUg0Z6qw8hvt9x2j8r2/Zur15rU/MNtwuSJj/qfS2ftBFfAY/f346mRDHWCiwIxV7vLbKBReysaUH7WSWJau5NXoeEVc7+1aV8iJzOLyd5lMHsc3vqpPQiY78rW9nNfeLO9yXj6gOs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=J0q7gCE5; arc=none smtp.client-ip=209.85.221.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="J0q7gCE5" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-4327790c4e9so1530031f8f.2 for ; Sat, 14 Feb 2026 18:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771124098; x=1771728898; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=2kMHVC9R3KhgqSgxiiKxf3157ayrLaqEXto3EAyfgiY=; b=J0q7gCE5coePngduF6fpVLNYehkVDZ8JkK0Ycoo5IwxxhwUrPNkpIyyViDjnBUXXi5 eIP7bZZ5mg6KTgZIx4kiGcUvmFT0u8PgVhlN9wZxL4qIetEY4X/jlL7Sd0Mq9GwoJ6kV mNe7ooMlPQsuT+TE5EknVMUkdQXwxiLg1i1ilr4MwLIAp1fU+WXwpCHcLLKFbroO6qsg K6hd1zXlQ+9hcE3wdnGow9Mr00FpReINrWup0sYJn2XzSDKmG1tpXZbe3Bbi4yM2c2Gb FOht6CwBKzrMvp+w77gRUhS94JBeRNg6FXyiaaGImGiwhb5+oHRUayMdOpRdQ2Z4b69Y 0eDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771124098; x=1771728898; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2kMHVC9R3KhgqSgxiiKxf3157ayrLaqEXto3EAyfgiY=; b=rqrgPEaTR5HQ1lBFugV6JVVfYkVblkgnR38ufZM8c8YXQZNkCkhNiJIyfRlDMOV5Pu MIOSapi7HnUKJAvOGok37JLiZAQtrnj5imHWT9NsC8n9zzqLDVi7/uRONzAUWIp26MuY s9nDllXPF4S5kU7uK1oK6e9BvJqwHjm9PQXbnNovck0L+mHW8KS6JTX/GlYmAuP2zRnl GK+1ivo87zNy/AlrUtL6wAq+6lsuiPP4FqSho/2XE4iNVIKKa99cDSQe0JOvGGTfso+1 EsK60NNuKDeDj0K3v7vZ2gjAne468Nt/1l1fBZOGs7ULBzkhylop6HocLmQoLyQ2qFH4 lhNg== X-Forwarded-Encrypted: i=1; AJvYcCXTyXODpddgfYigoIVguc3niMyk0hdiiGuEEzJC14i7pSufqmHWYd28RD1vm0KYgP4XLpqDXHs7n+yAL5A=@vger.kernel.org X-Gm-Message-State: AOJu0YxDtQBDLnM/pICILxs6/ipfSG8tMCTH09SVgI9jIBf30Fx2K8o9 jMM2KK5JmgusuY3izTPOGbUu3tmZv53KwcXFkiSzTylTuDub4zfLY4L8 X-Gm-Gg: AZuq6aI7njei0NM9dwdf/DrLLF/bjCK6u8W7RXXHljxmjtmst33jk859iBET3lwKT2+ kLqg+/ConWDeSVFn1F+d2/aT2bs85qr08LZFiItLW4YjiliVJIye/WH1MO1VJpmBrymGMGJiu4r D/yL0wRwWI6cugwaQ7uyFtnonGZhlaryKp0ZsO6KCHLPTJtpbdRltHJ69nRAkluF1doLAsfEqyC 2OeGtoOZIvGM6r1Sl2mWfjc3VxG3JmvyEkwQIK2rMjZLb2HqMgZGXX6TcC5fZitozht9pYIM47E pFNy5kPJOAWZLehn1DaPCJwoz5IrMMU8ujUoYIC9wKKxPqC3TfovrV0W6dUoita/eaXqC0xkx2j ZEtJPh/t1oBt0ZhEE9SCUHGeynzxw8ggTYf4kPLmdCrjlOZhszYxZIRKjzlhoOYPhwSsfNlFjco dE2iFZGO9LLbOh04D0Xbc3+MG48yQTY2aCDyNXeWEzErbZlX1g6Xl1Zg== X-Received: by 2002:a05:6000:1842:b0:437:6d8c:c08a with SMTP id ffacd0b85a97d-43796af9dc8mr13792216f8f.45.1771124097834; Sat, 14 Feb 2026 18:54:57 -0800 (PST) Received: from Ansuel-XPS. (93-34-90-125.ip49.fastwebnet.it. [93.34.90.125]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796a5ac92sm16579708f8f.1.2026.02.14.18.54.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Feb 2026 18:54:57 -0800 (PST) Message-ID: <69913581.5d0a0220.340e.3d3e@mx.google.com> X-Google-Original-Message-ID: Date: Sun, 15 Feb 2026 03:54:54 +0100 From: Christian Marangi To: David Disseldorp Cc: Nathan Chancellor , Nicolas Schier , Dmitry Safonov <0x7f454c46@gmail.com>, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, "linux-fsdevel@vger.kernel.org" Subject: Re: [RFC PATCH] initramfs: correctly handle space in path on cpio list generation References: <20260209153800.28228-1-ansuelsmth@gmail.com> <20260210223431.6bf63673.ddiss@suse.de> <698b6ced.050a0220.9e34a.3e08@mx.google.com> <20260211113308.4c5b0b82.ddiss@suse.de> <698bd439.050a0220.38f6b4.a251@mx.google.com> <20260211134025.57a4d249.ddiss@suse.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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