From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Filip Schauer <f.schauer@proxmox.com>
Subject: [pve-devel] applied: [PATCH common] tools: explain reason for the explicit PerlIO load
Date: Mon, 3 Feb 2025 12:13:20 +0100 [thread overview]
Message-ID: <72c313ca-95d7-4322-a789-89003c1eda6f@proxmox.com> (raw)
In-Reply-To: <20241202160324.139854-1-f.schauer@proxmox.com>
Am 02.12.24 um 17:03 schrieb Filip Schauer:
> Explain the reason for the explicit `use PerlIO::scalar;` statement
> introduced in c4945bf ("tools: load PerlIO explicitly to avoid odd
> failures")
>
> Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
> ---
> src/PVE/Tools.pm | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/PVE/Tools.pm b/src/PVE/Tools.pm
> index 0325f53..57eb86c 100644
> --- a/src/PVE/Tools.pm
> +++ b/src/PVE/Tools.pm
> @@ -290,12 +290,12 @@ sub file_set_contents {
> } else {
> # Encode wide characters with print before passing them to syswrite
> my $unencoded_data = $data;
> - # Without this we get some "Can't locate PerlIO.pm in @INC" errors _sometimes_, and the
> - # odd thing about it is that they can be "fixed" by calling file_set_contents in the
> - # parent methode/code before the method, from another module, is called.
> - # Anyway, loading PerlIO here should be fine as the in-memory variable writing is in
> - # fact backed by the PerlIO based "scalar" module. This comment can be removed once the
> - # odd behavior is really understood.
> + # Preload PerlIO::scalar at compile time to prevent runtime loading issues when
> + # file_set_contents is called with PVE::LXC::Setup::protected_call. Normally,
> + # PerlIO::scalar is loaded implicitly during the execution of
> + # `open(my $data_fh, '>', \$data)`. However, this fails if it is executed within a
> + # chroot environment where the necessary PerlIO.pm module file is inaccessible.
> + # Preloading the module ensures it is available regardless of the execution context.
> use PerlIO::scalar;
> open(my $data_fh, '>', \$data) or die "failed to open in-memory variable - $!\n";
> print $data_fh $unencoded_data;
Nice detective work! Applied, thanks!
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-02-03 11:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 16:03 [pve-devel] " Filip Schauer
2025-02-03 11:13 ` Fiona Ebner [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=72c313ca-95d7-4322-a789-89003c1eda6f@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=f.schauer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.