Goswin von Brederlow wrote:
I think 0 size files are just a case of partial files that isn't
handled special. With other partial files you want to keep them and
resume downloading. With 0 bytes there is 0 gain in resuming but
removing them would haven been extra code.
I think the bigger question is where those files come from in the
first place. Where does it start fetching them and quits after 0
bytes? Maybe that apt method should not create the files unless it
actualy has data to write to them in the first place.
I uploaded my strace reports to a public location:
http://members.lycos.nl/kattouw/traces/ contains reports of an apt-get
update spewing errors, while
http://members.lycos.nl/kattouw/traces/traces2 contains reports of
apt-get update running on an empty partial dir.
According to the second series, the methods/ftp helper program is
responsible for creating those files. After negotiating a lot with the
remote FTP server (strace cuts strings at 32 chars, so I didn't see
those negotiations. The uploaded reports do show them, but I didn't
really feel like reading them at 1 AM) and stat(2)ing a non-existent
partial file, it creates one by open(2)ing it with the O_CREAT flag set
(i.e. opening it in destructive write mode). These reports may clarify
things a little about why those empty partial files are created.
The most logical scheme would be to create a partial file only when
we're sure we're actually going to receive data to put in it, backup all
the data we receive into it, and remove it as soon as we know we've got
everything. An alternative would be to remove all empty partial files at
cleanup, but that's ugly and still causes trouble when apt-get dies
unexpectedly.
NB: If you're really curious, the command line used to generate the
strace reports was
strace -o trace -ff -s 300 apt-get update
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
