[pve-devel] appllied: [PATCH] read firstline: only map ENOENT to undef, raise error otherwise

[pve-devel] appllied: [PATCH] read firstline: only map ENOENT to undef, raise error otherwise

[Thomas Lamprecht]

Errors like permission denied or I/O ones should bubble up, otherwise
it might hide serious issues and seemingly continue to work, with a
wrong state or the like.

One could argue that the case for not existent should return undef,
while an empty file should return an empty string, but for that we
might want to check all use-sites first.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
---
 src/PVE/Tools.pm | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/PVE/Tools.pm b/src/PVE/Tools.pm
index 174ded8..2d728f8 100644
--- a/src/PVE/Tools.pm
+++ b/src/PVE/Tools.pm
@@ -291,7 +291,10 @@ sub file_read_firstline {
     my ($filename) = @_;
 
     my $fh = IO::File->new ($filename, "r");
-    return undef if !$fh;
+    if (!$fh) {
+	return undef if $! == POSIX::ENOENT;
+	die "file '$filename' exists but open for reading failed - $!\n";
+    }
     my $res = <$fh>;
     chomp $res if $res;
     $fh->close;
-- 
2.39.2

Re: [pve-devel] appllied: [PATCH] read firstline: only map ENOENT to undef, raise error otherwise

[Dietmar Maurer]

> One could argue that the case for not existent should return undef,
> while an empty file should return an empty string, but for that we
> might want to check all use-sites first.

AFAIR I use this function many times assuming that it does not throw errors in case of empty files. That is quite convenient.

Re: [pve-devel] appllied: [PATCH] read firstline: only map ENOENT to undef, raise error otherwise

[Thomas Lamprecht]

Am 13/06/2023 um 07:27 schrieb Dietmar Maurer:
>> One could argue that the case for not existent should return undef,
>> while an empty file should return an empty string, but for that we
>> might want to check all use-sites first.
> 
> AFAIR I use this function many times assuming that it does not throw errors in case of empty files. That is quite convenient.

Yes, and it still doesn't errors in that case. Above is talking about differentiating
the not-existing, empty file and empty first-line cases.

Currently (and before my patch) the behavior is:

- file does not exist -> undef
- file exists but empty -> undef
- file exists but first line empty -> ''

It would be a bit more expected to have the "file exists but empty" case also return
an empty string, but it probably doesn't matter.