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

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
=== modified file 'debian/changelog'
--- debian/changelog 2009-04-30 20:32:06 +0000
+++ debian/changelog 2009-08-31 16:31:58 +0000
@@ -1,3 +1,9 @@
1zsync (0.6-1ubuntu2) karmic; urgency=low
2
3 * http.c: fixup offsets that are larger than signed ints (LP: #420931)
4
5 -- Steve Beattie <sbeattie@ubuntu.com> Mon, 31 Aug 2009 02:14:24 -0700
6
1zsync (0.6-1ubuntu1) karmic; urgency=low7zsync (0.6-1ubuntu1) karmic; urgency=low
28
3 * Merge with Debian unstable (LP: #301291). Remaining changes:9 * Merge with Debian unstable (LP: #301291). Remaining changes:
410
=== modified file 'http.c'
--- http.c 2009-04-30 20:32:06 +0000
+++ http.c 2009-08-31 16:31:58 +0000
@@ -1006,11 +1006,23 @@
10061006
1007 /* Otherwise, we're reading the MIME headers for this part until we get \r\n alone */1007 /* Otherwise, we're reading the MIME headers for this part until we get \r\n alone */
1008 for (; buf[0] != '\r' && buf[0] != '\n' && buf[0] != '\0';) {1008 for (; buf[0] != '\r' && buf[0] != '\n' && buf[0] != '\0';) {
1009 int from, to;1009 off_t from, to;
1010 if (!rfgets(buf,sizeof(buf),rf)) return 0;1010
1011 buflwr(buf);1011 /* Get next header */
1012 if (2 == sscanf(buf,"content-range: bytes %d-%d/",&from,&to)) {1012 if (!rfgets(buf, sizeof(buf), rf))
1013 rf->offset = from - global_offset; rf->block_left = to - from + 1; gotr = 1;1013 return 0;
1014 buflwr(buf); /* HTTP headers are case insensitive */
1015
1016 /* We're looking for the Content-Range: header, to tell us how
1017 * many bytes and what part of the target file they represent.
1018 */
1019 if (2 ==
1020 sscanf(buf,
1021 "content-range: bytes " OFF_T_PF "-" OFF_T_PF "/",
1022 &from, &to)) {
1023 rf->offset = from - global_offset;
1024 rf->block_left = to - from + 1;
1025 gotr = 1;
1014 }1026 }
1015 }1027 }
10161028

Subscribers

People subscribed via source and target branches

to all changes: