[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9800: Incomplete truncated file buffers from the /proc filesystem
From: |
Arsen Arsenović |
Subject: |
bug#9800: Incomplete truncated file buffers from the /proc filesystem |
Date: |
Sun, 12 Feb 2023 11:21:29 +0100 |
Hi,
I was just debugging this before I found the bug report. The diagnosis
is right: st_size is wrong for proc files (and, I'd argue, for regular
files sometimes). So, I agree with Paul.
Paul Eggert <eggert@cs.ucla.edu> writes:
> On 10/24/11 14:50, Richard Stallman wrote:
>> I think there was a reason for doing it this way. Perhaps so as to
>> allocate the space before reading the file.
>
> Yes, that sounds right. And in the typical case where the file is not
> growing, that allocates space efficiently. If the file is growing, though,
> it's OK to allocate more space after discovering that the initial
> allocation was too small.
Right. The best possible approach is, likely:
fstat (fd, x, &st)
bufsz = max (READ_BUF_SIZE, st.st_size)
buf = malloc (bufsz)
int ret = 0, readsz = 0;
do
{
readsz += ret;
if (readsz == bufsz && size isn't unreasonable)
{
/* value chosen arbitrarily. */
bufsz += min (16 * READ_BUF_SIZE, bufsz)
buf = realloc (buf, bufsz)
}
errno = 0
ret = read (fd, buf + readsz, bufsz - readsz)
}
while (ret > 0 || errno == EINTR);
... or such. This approach is robust and general, and I suspect it'd
even work for named pipes.
st_size isn't a good enough indicator of size, and it can go out of date
before TOU, however, it's - no doubt - a useful hint in the 99% case.
Using st_size to figure out a base allocation size and extending
appropriately is a well known strategy, and it would be appropriate to
do so here.
Thanks in advance, have a great day.
--
Arsen Arsenović
signature.asc
Description: PGP signature