Comment 4 for bug 524919

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 address hidden>
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?