On 2012-08-06 00:16:14, Ben Hutchings wrote: > On Wed, 2012-08-01 at 12:11 -0300, Herton Ronaldo Krzesinski wrote: > > Hi, > > > > please consider including the following commit into 2.6.32.y, 3.0.y, > > 3.2.y: > > > > commit 4a26620df451ad46151ad21d711ed43e963c004e > > Author: Tyler Hicks <[email protected]> > > Date: Sat Nov 5 13:45:08 2011 -0400 > > > > eCryptfs: Improve statfs reporting > > > > It fixes bug https://bugs.launchpad.net/ecryptfs/+bug/885744, but didn't > > had an Cc stable on it. > > > > I noted while running ecryptfs tests on stables that the test for the bug > > was failing. > > > > The fix cherry-picks cleanly on 3.0 and 3.2. For 2.6.32, an backport is > > needed, the attached backport from Ubuntu 2.6.32 should work. If 2.6.34 > > or 2.6.35 are still maintained, feel free to include it too, I can > > provide backported versions if needed. > > This isn't a bug fix; it's a regression. pathconf(_PC_NAME_MAX) needs > to report an upper bound on the maximum name length, not a lower bound, > so that readdir_r() can be used safely.
You're right. I was obviously only thinking about using pathconf(_PC_NAME_MAX) to make sure a given filename would be usable in an eCryptfs mount, not to determine buffer sizes when reading existing filenames. I can't remember the details now, but I was having trouble getting a good calculation on the upper bound. I'll revisit it, get a fix in, mark it for the stable tree and mention that it requires 4a26620df451ad46151ad21d711ed43e963c004e. Thanks for the review, Ben. Tyler > > Ben. > > -- > Ben Hutchings > Theory and practice are closer in theory than in practice. > - John Levine, moderator of comp.compilers
signature.asc
Description: Digital signature
