Ubuntu
zsync package

Merge lp:~sbeattie/ubuntu/karmic/zsync/zsync-fixups into lp:ubuntu/karmic/zsync

  1. Karmic (9.10)
  2. zsync-fixups
  3. Merge into karmic
Proposed by Steve Beattie
Status: Merged
Merged at revision: not available
Proposed branch: lp:~sbeattie/ubuntu/karmic/zsync/zsync-fixups
Merge into: lp:ubuntu/karmic/zsync
Diff against target: None lines
To merge this branch: bzr merge lp:~sbeattie/ubuntu/karmic/zsync/zsync-fixups
Reviewer Review Type Date Requested Status
James Westby (community) Approve
Review via email: mp+10931@code.launchpad.net
To post a comment you must log in.
Revision history for this message
Steve Beattie (sbeattie) wrote :

In the last sync, from and to were reverted from off_t (64bit types) to ints, which suffers from signed overflow when the partially downloaded file is larger than 2GB. This fix reverts most of the merge's change for this section, while keeping the intent, which is to take global_offset into account when computing rf->offset. I've tested this fix and it causes zsync to successfully download daily dvds where the 0.6-1ubuntu1 would consistently SEGV. It would be nice if this could be merged for alpha 5, since iso testers for that release may want to use zsync to grab the images for testing.

Revision history for this message
James Westby (james-w) wrote :

Thanks Steve, uploaded.

James

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'debian/changelog'
2--- debian/changelog 2009-04-30 20:32:06 +0000
3+++ debian/changelog 2009-08-31 16:31:58 +0000
4@@ -1,3 +1,9 @@
5+zsync (0.6-1ubuntu2) karmic; urgency=low
6+
7+ * http.c: fixup offsets that are larger than signed ints (LP: #420931)
8+
9+ -- Steve Beattie <sbeattie@ubuntu.com> Mon, 31 Aug 2009 02:14:24 -0700
10+
11 zsync (0.6-1ubuntu1) karmic; urgency=low
12
13 * Merge with Debian unstable (LP: #301291). Remaining changes:
14
15=== modified file 'http.c'
16--- http.c 2009-04-30 20:32:06 +0000
17+++ http.c 2009-08-31 16:31:58 +0000
18@@ -1006,11 +1006,23 @@
19
20 /* Otherwise, we're reading the MIME headers for this part until we get \r\n alone */
21 for (; buf[0] != '\r' && buf[0] != '\n' && buf[0] != '\0';) {
22- int from, to;
23- if (!rfgets(buf,sizeof(buf),rf)) return 0;
24- buflwr(buf);
25- if (2 == sscanf(buf,"content-range: bytes %d-%d/",&from,&to)) {
26- rf->offset = from - global_offset; rf->block_left = to - from + 1; gotr = 1;
27+ off_t from, to;
28+
29+ /* Get next header */
30+ if (!rfgets(buf, sizeof(buf), rf))
31+ return 0;
32+ buflwr(buf); /* HTTP headers are case insensitive */
33+
34+ /* We're looking for the Content-Range: header, to tell us how
35+ * many bytes and what part of the target file they represent.
36+ */
37+ if (2 ==
38+ sscanf(buf,
39+ "content-range: bytes " OFF_T_PF "-" OFF_T_PF "/",
40+ &from, &to)) {
41+ rf->offset = from - global_offset;
42+ rf->block_left = to - from + 1;
43+ gotr = 1;
44 }
45 }
46

Subscribers

People subscribed via source and target branches

to all changes: