dpkg 1.17.24 trashing files
Hello,
I don't file a bug report since there's no much I can say and I have
no means to be able to debug it further since I have to fix it ASAP.
You may or may not be able to see what's going on, or at least aware
of this possibly happening.
A machine (jessie) wasn't upgraded in a while, dpkg was at
1.16.15_amd64. I started selectively upgrading, namely aptitude first,
then dpkg, and let aptitude pull anything required.
After installing dpkg_1.17.24_amd64 everything started crashing really hard.
It turned out that most files had 0x00 appended at their end, like
bash_completion.sh (making it non-exacutable), READMEs and possibly
others. I've tried to strace it but I dont' see obvius obvious
problem.
This is one file I have tested the problem on:
lstat("/usr/share/doc/bc/README", {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
rmdir("/usr/share/doc/bc/README.dpkg-new") = -1 ENOENT (No such file
or directory)
rmdir("/usr/share/doc/bc/README.dpkg-tmp") = -1 ENOENT (No such file
or directory)
open("/usr/share/doc/bc/README.dpkg-new", O_WRONLY|O_CREAT|O_EXCL, 0) = 11
fallocate(11, 0, 0, 3522) = 0
read(10, "GNU bc version 1.06:\n\nExtra configuration options:\n\n
.... value of\neach print as the number is
printed.\n-----------------------------------------------------------------------\n",
3522) = 3522
write(11, "GNU bc version 1.06:\n\nExtra configuration options:\n\n
....... print as the number is
printed.\n-----------------------------------------------------------------------\n",
3522) = 3522
So far it looks good, there are no \0 at the end.
lseek(10, 62, SEEK_CUR) = -1 ESPIPE (Illegal seek)
read(10, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
62) = 62
sync_file_range(11, 0, 0, SYNC_FILE_RANGE_WRITE) = 0
fchown(11, 0, 0) = 0
fchmod(11, 0644) = 0
close(11) = 0
utimes("/usr/share/doc/bc/README.dpkg-new", {{1428000304, 0},
{1254697207, 0}}) = 0
link("/usr/share/doc/bc/README", "/usr/share/doc/bc/README.dpkg-tmp") = 0
I don't spot what happens, but I believe at this point there are
approximately 62 x \0 at the end of the file.
Downgrading to 1.16.15 seems to have fixed the problem.
Peter
Reply to: