Yes, I was running it fine a couple days of earlier, but we did get a
dpkg update on 14 Feb.
The assert was committed on Sep 2009 in dpkg:
- do {
- varbufextend(&symlinkfn);
- r= readlink(fnamevb.buf,symlinkfn.buf,symlinkfn.size);
- if (r<0) ohshite(_("unable to read link `%.255s'"),ti->Name);
- } while ((size_t)r == symlinkfn.size);
+ varbuf_grow(&symlinkfn, stab.st_size + 1);
+ r = readlink(fnamevb.buf, symlinkfn.buf, symlinkfn.size);
+ if (r < 0)
+ ohshite(_("unable to read link `%.255s'"), ti->Name);
+ assert(r == stab.st_size);
commit 353b02acb33224bc2d7e3b0295538d592b9c8bad
Author: Guillem Jover <[email protected]>
Date: Wed Sep 30 03:10:27 2009 +0200
dpkg: Use stat size to varbuf_grow the buffer for readlink
Do not expand the buffer indefinitely by trying several times until
the buffer is big enough. Pre-allocate just once using varbuf_grow
with the known size from stat.
that said, I find it hard to blame the dpkg developers for assuming that
behavior given that it's the documented one.
Wouldn't it make more sense to consistently return unencrypted
sizes/metadata for all syscalls on ecryptfs files?
** Also affects: dpkg (Ubuntu)
Importance: Undecided
Status: New
--
ecryptfs breaks lstat/readlink size assumption
https://bugs.launchpad.net/bugs/524919
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
