OK, it looks like this is going to get fixed in the kernel. Closing this here.
In case the kernel fix won't make feel free to re-open the discussion.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-sof
Closed #1740.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1740#event-5167720271___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Thank you for the responses! I understand the problem(s) of this pull request.
I have two questions:
1. Why is the archive size calculated in advance in the first place? Is this
some kind of sanity check or is it required somewhere?
2. Would it be possible, in case the size check fails, to give
> But I am hesitant to merge this just to work around what looks to me like a
> very obvious bug in an file system. Let's keep this open until we see where
> [google/fscrypt#305](https://github.com/google/fscrypt/issues/305) is going.
> But I suspect this issue is going to get fixed (hopefully)
Also note that `PATH_MAX` is not a good value for sizing stack buffers: on some
systems (ex: GNU/Hurd) it is an absurdly large value. Paths should be
allocated on the heap instead.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on G
Thanks for this very thorough analysis and bug report!
But I am hesitant to merge this just to work around what looks to me like a
very obvious bug in an file system. Let's keep this open until we see where
https://github.com/google/fscrypt/issues/305 is going. But I suspect this issue
is going
Reference Issues
#1682
What does this fix?
The man page of `stat()` mentions that for symbolic links the length of the
pointed-to path is stored in `stat.st_size`. However, as reported
[here](https://github.com/rpm-software-management/rpm/issues/1682) and
[here](https://github.com/
