From nobody@FreeBSD.org  Wed Oct 17 17:41:55 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B7AFF16A4E1
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 17 Oct 2007 17:41:55 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 8664113C4AC
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 17 Oct 2007 17:41:54 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l9HHfgJX070162
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 17 Oct 2007 17:41:42 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.1/8.14.1/Submit) id l9HHfgdE070161;
	Wed, 17 Oct 2007 17:41:42 GMT
	(envelope-from nobody)
Message-Id: <200710171741.l9HHfgdE070161@www.freebsd.org>
Date: Wed, 17 Oct 2007 17:41:42 GMT
From: Fabian Keil <fk@fabiankeil.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [PATCH] fetch's resume mode doesn't verify that it actually got partial content
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         117277
>Category:       bin
>Synopsis:       [patch] fetch(1): fetch's resume mode doesn't verify that it actually got partial content
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    des
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct 17 17:50:01 UTC 2007
>Closed-Date:    Mon Nov 05 13:03:35 UTC 2012
>Last-Modified:  Mon Nov 05 13:03:35 UTC 2012
>Originator:     Fabian Keil
>Release:        RELENG_7
>Organization:
>Environment:
FreeBSD TP51.local 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Mon Oct 15 18:31:16 CEST 2007     fk@TP51.local:/usr/obj/usr/src/sys/THINKPAD  i386
>Description:
When resuming a file over HTTP, fetch(1) treats complete retransmits
like partial content and appends the whole response to the
already existing part that was fetched earlier.

The problem shows if the server doesn't support Range requests
or if the proxy strips out the Range header to prevent range
mismatches (which could happen if the proxy modified the first
response):

fk@TP51 /tank/fetch-tests $fetch -r http://10.0.0.1/BrooksDavis.EuroBSDCon.2007.avi
BrooksDavis.EuroBSDCon.2007.avi                30% of   92 MB 8440 kBps^C
fetch: transfer interrupted

fk@TP51 /tank/fetch-tests $fetch -r http://10.0.0.1/BrooksDavis.EuroBSDCon.2007.avi
BrooksDavis.EuroBSDCon.2007.avi               100% of   92 MB   17 MBps
fk@TP51 /tank/fetch-tests $ls -lh
total 123649
-rw-r--r--  1 fk  wheel   121M Sep 25 21:01 BrooksDavis.EuroBSDCon.2007.avi


>How-To-Repeat:
Resume a file from a HTTP server that doesn't support
Range requests or with a proxy that removes the Range
header.
>Fix:
While fetch(3) doesn't pass the HTTP status code to fetch(1),
the problem can be solved by checking the content offset.

If the offset is zero, the response contains the whole file
and the already existing part of it has to be overwritten.

With the attached patch it works as expected:

fk@TP51 /tank/fetch-tests $rm BrooksDavis.EuroBSDCon.2007.avi 
fk@TP51 /tank/fetch-tests $fetch -r http://10.0.0.1/BrooksDavis.EuroBSDCon.2007.avi
BrooksDavis.EuroBSDCon.2007.avi                58% of   92 MB   15 MBps^C
fetch: transfer interrupted

fk@TP51 /tank/fetch-tests $fetch -r http://10.0.0.1/BrooksDavis.EuroBSDCon.2007.avi
BrooksDavis.EuroBSDCon.2007.avi               100% of   92 MB   13 MBps
fk@TP51 /tank/fetch-tests $ls -lh
total 95081
-rw-r--r--  1 fk  wheel    93M Sep 25 21:01 BrooksDavis.EuroBSDCon.2007.avi


Patch attached with submission follows:

--- .zfs/snapshot/2007-10-15/usr.bin/fetch/fetch.c	2006-11-10 23:05:41.000000000 +0100
+++ usr.bin/fetch/fetch.c	2007-10-16 14:21:20.221581714 +0200
@@ -488,8 +488,11 @@
 	if (o_stdout) {
 		/* output to stdout */
 		of = stdout;
-	} else if (r_flag && sb.st_size != -1) {
-		/* resume mode, local file exists */
+	} else if (r_flag && sb.st_size != -1 && url->offset) {
+		/*
+		 * resume mode, local file exists and we
+		 * actually received partial content as requested
+		 */
 		if (!F_flag && us.mtime && sb.st_mtime != us.mtime) {
 			/* no match! have to refetch */
 			fclose(f);


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->des 
Responsible-Changed-By: delphij 
Responsible-Changed-When: Wed Oct 17 19:17:03 UTC 2007 
Responsible-Changed-Why:  
I think Dag-Erling will be more authoritive on libfetch(3) related stuff. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=117277 

From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Fabian Keil <fk@fabiankeil.de>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/117277: [PATCH] fetch's resume mode doesn't verify that it actually got partial content
Date: Thu, 18 Oct 2007 09:48:59 +0200

 Fabian Keil <fk@fabiankeil.de> writes:
 > --- .zfs/snapshot/2007-10-15/usr.bin/fetch/fetch.c	2006-11-10 23:05:41.00=
 0000000 +0100
 > +++ usr.bin/fetch/fetch.c	2007-10-16 14:21:20.221581714 +0200
 > @@ -488,8 +488,11 @@
 >  	if (o_stdout) {
 >  		/* output to stdout */
 >  		of =3D stdout;
 > -	} else if (r_flag && sb.st_size !=3D -1) {
 > -		/* resume mode, local file exists */
 > +	} else if (r_flag && sb.st_size !=3D -1 && url->offset) {
 > +		/*
 > +		 * resume mode, local file exists and we
 > +		 * actually received partial content as requested
 > +		 */
 >  		if (!F_flag && us.mtime && sb.st_mtime !=3D us.mtime) {
 >  			/* no match! have to refetch */
 >  			fclose(f);
 
 For extra credit, the code should check that url->offset is actually in
 the (0, sb.st_size) range, and lseek to url->offset before resuming the
 transfer.
 
 DES
 --=20
 Dag-Erling Sm=C3=B8rgrav - des@des.no

From: Fabian Keil <fk@fabiankeil.de>
To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/117277: [PATCH] fetch's resume mode doesn't verify that it
 actually got partial content
Date: Thu, 18 Oct 2007 21:14:46 +0200

 Dag-Erling Sm=F8rgrav <des@des.no> wrote:
 
 > Fabian Keil <fk@fabiankeil.de> writes:
 > > --- .zfs/snapshot/2007-10-15/usr.bin/fetch/fetch.c	2006-11-10
 > > 23:05:41.000000000 +0100 +++ usr.bin/fetch/fetch.c	2007-10-16
 > > 14:21:20.221581714 +0200 @@ -488,8 +488,11 @@
 > >  	if (o_stdout) {
 > >  		/* output to stdout */
 > >  		of =3D stdout;
 > > -	} else if (r_flag && sb.st_size !=3D -1) {
 > > -		/* resume mode, local file exists */
 > > +	} else if (r_flag && sb.st_size !=3D -1 && url->offset) {
 > > +		/*
 > > +		 * resume mode, local file exists and we
 > > +		 * actually received partial content as requested
 > > +		 */
 > >  		if (!F_flag && us.mtime && sb.st_mtime !=3D us.mtime) {
 > >  			/* no match! have to refetch */
 > >  			fclose(f);
 >=20
 > For extra credit, the code should check that url->offset is actually in
 > the (0, sb.st_size) range, and lseek to url->offset before resuming the
 > transfer.
 
 Due to ENOTIME I have to let this unique
 opportunity for extra credit pass by.
 
 Fabian
State-Changed-From-To: open->analyzed 
State-Changed-By: des 
State-Changed-When: Fri May 13 07:58:58 UTC 2011 
State-Changed-Why:  
Currently testing a patch. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=117277 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/117277: commit references a PR
Date: Thu, 15 Sep 2011 22:50:46 +0000 (UTC)

 Author: des
 Date: Thu Sep 15 22:50:31 2011
 New Revision: 225599
 URL: http://svn.freebsd.org/changeset/base/225599
 
 Log:
   When resuming an HTTP download, we failed to verify that the range
   returned by the server matched what we requested, and blindly appended
   what we received to what we already had.  This could go two ways: if the
   delivered offset was higher than expected, the local file would contain
   duplicate data, while if it was lower than expected, there would be data
   missing from the middle of the file.  Furthermore, if the transfer was
   interrupted again, each subsequent attempt would compound the error.
   Fix the first problem by restarting the transfer from scratch if there
   is a gap, and the second by explicitly seeking to the correct location
   in the local file so as to overwrite any duplicated data.
   
   PR:		bin/117277
   Approved by:	re (kib)
   MFC after:	3 weeks
 
 Modified:
   head/usr.bin/fetch/fetch.c
 
 Modified: head/usr.bin/fetch/fetch.c
 ==============================================================================
 --- head/usr.bin/fetch/fetch.c	Thu Sep 15 22:14:35 2011	(r225598)
 +++ head/usr.bin/fetch/fetch.c	Thu Sep 15 22:50:31 2011	(r225599)
 @@ -522,6 +522,12 @@ fetch(char *URL, const char *path)
  				    "does not match remote", path);
  				goto failure_keep;
  			}
 +		} else if (url->offset > sb.st_size) {
 +			/* gap between what we asked for and what we got */
 +			warnx("%s: gap in resume mode", URL);
 +			fclose(of);
 +			of = NULL;
 +			/* picked up again later */
  		} else if (us.size != -1) {
  			if (us.size == sb.st_size)
  				/* nothing to do */
 @@ -551,6 +557,14 @@ fetch(char *URL, const char *path)
  				fclose(of);
  				of = NULL;
  				sb = nsb;
 +				/* picked up again later */
 +			}
 +			/* seek to where we left off */
 +			if (of != NULL && fseek(of, url->offset, SEEK_SET) != 0) {
 +				warn("%s: fseek()", path);
 +				fclose(of);
 +				of = NULL;
 +				/* picked up again later */
  			}
  		}
  	} else if (m_flag && sb.st_size != -1) {
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: analyzed->patched 
State-Changed-By: des 
State-Changed-When: Thu Sep 15 23:24:40 UTC 2011 
State-Changed-Why:  
Fixed in head 

http://www.freebsd.org/cgi/query-pr.cgi?pr=117277 

From: Fabian Keil <fk@fabiankeil.de>
To: des@FreeBSD.org
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/117277: [patch] fetch(1): fetch's resume mode doesn't
 verify that it actually got partial content
Date: Mon, 19 Sep 2011 11:52:05 +0200

 --Sig_/=7IF5cq8b6GDX+cR1nbYMx_
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 The fix in HEAD doesn't seem to address the issue I reported.
 
 Complete responses are still appended to the partial content
 fetched previously, resulting in a broken file with duplicated
 data.
 
 The submitted patch still applies and works for me, though.
 
 Fabian
 
 --Sig_/=7IF5cq8b6GDX+cR1nbYMx_
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (FreeBSD)
 
 iEYEARECAAYFAk53ESEACgkQSMVSH78upWM6TgCggupJmkK0w854sjopW6JgaYg5
 32cAnjeDwbLl8hUv4ZZjIqkvW/3jNdAr
 =Qzby
 -----END PGP SIGNATURE-----
 
 --Sig_/=7IF5cq8b6GDX+cR1nbYMx_--

From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Fabian Keil <fk@fabiankeil.de>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/117277: [patch] fetch(1): fetch's resume mode doesn't verify that it actually got partial content
Date: Thu, 22 Sep 2011 14:13:33 +0200

 Fabian Keil <fk@fabiankeil.de> writes:
 > Complete responses are still appended to the partial content
 > fetched previously, resulting in a broken file with duplicated
 > data.
 
 I think I see the error.  Can you take the } on line 568 and move it up
 to right before line 562 ("seek to where we left off") and test again?
 
 Actually, that } should probably move up to right before line 547
 ("check that it didn't move under our feet"), but one thing at a time...
 
 DES
 --=20
 Dag-Erling Sm=C3=B8rgrav - des@des.no

From: Fabian Keil <fk@fabiankeil.de>
To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/117277: [patch] fetch(1): fetch's resume mode doesn't
 verify that it actually got partial content
Date: Sat, 24 Sep 2011 10:40:04 +0200

 --Sig_/cZyitqs_.z03bVleGFdLr/5
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Dag-Erling Sm=F8rgrav <des@des.no> wrote:
 
 > Fabian Keil <fk@fabiankeil.de> writes:
 > > Complete responses are still appended to the partial content
 > > fetched previously, resulting in a broken file with duplicated
 > > data.
 >=20
 > I think I see the error.  Can you take the } on line 568 and move it up
 > to right before line 562 ("seek to where we left off") and test again?
 
 This:
 
 --- a/usr.bin/fetch/fetch.c
 +++ b/usr.bin/fetch/fetch.c
 @@ -559,13 +559,13 @@ fetch(char *URL, const char *path)
                                 sb =3D nsb;
                                 /* picked up again later */
                         }
 -                       /* seek to where we left off */
 -                       if (of !=3D NULL && fseek(of, url->offset, SEEK_SET=
 ) !=3D 0) {
 -                               warn("%s: fseek()", path);
 -                               fclose(of);
 -                               of =3D NULL;
 -                               /* picked up again later */
 -                       }
 +               }
 +               /* seek to where we left off */
 +               if (of !=3D NULL && fseek(of, url->offset, SEEK_SET) !=3D 0=
 ) {
 +                       warn("%s: fseek()", path);
 +                       fclose(of);
 +                       of =3D NULL;
 +                       /* picked up again later */
                 }
 
 doesn't seem to work:
 
 fk@r500 /tank/scratch $/usr/obj/usr/src/usr.bin/fetch/fetch -aRr http://10.=
 0.0.1:81/1G-file
 1G-file                                        35% of 1024 MB   40 MBps^C
 fetch: transfer interrupted
 
 fk@r500 /tank/scratch $/usr/obj/usr/src/usr.bin/fetch/fetch -aRr http://10.=
 0.0.1:81/1G-file
 1G-file                                       100% of 1024 MB   39 MBps 00m=
 00s
 fk@r500 /tank/scratch $ls -lh 1G-file
 -rw-r-----  1 fk  fk   1.4G Sep 24 09:48 1G-file
 
 I think this is because the file is opened in append mode.
 Quoting fopen(3):
 |     ``a''   Open for writing.  The file is created if it does not exist. =
  The
 |             stream is positioned at the end of the file.  Subsequent writ=
 es
 |             to the file will always end up at the then current end of fil=
 e,
 |             irrespective of any intervening fseek(3) or similar.
 
 I guess this means the fseek() had no effect in the previous
 location either, although I didn't test it.
 
 Fabian
 
 --Sig_/cZyitqs_.z03bVleGFdLr/5
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (FreeBSD)
 
 iEYEARECAAYFAk59l2kACgkQSMVSH78upWONNwCdHAmIiZgbvQl3IgbkhXWLvF6O
 Gk8An3Itry3RaxfUBMmSThQibJDiNcYF
 =olSy
 -----END PGP SIGNATURE-----
 
 --Sig_/cZyitqs_.z03bVleGFdLr/5--

From: Fabian Keil <fk@fabiankeil.de>
To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/117277: [patch] fetch(1): fetch's resume mode doesn't
 verify that it actually got partial content
Date: Sat, 24 Sep 2011 13:17:09 +0200

 --Sig_/VK+iB09RJd20nb=+mFhcLyA
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Fabian Keil <fk@fabiankeil.de> wrote:
 
 > Dag-Erling Sm=F8rgrav <des@des.no> wrote:
 >=20
 > > Fabian Keil <fk@fabiankeil.de> writes:
 > > > Complete responses are still appended to the partial content
 > > > fetched previously, resulting in a broken file with duplicated
 > > > data.
 > >=20
 > > I think I see the error.  Can you take the } on line 568 and move it up
 > > to right before line 562 ("seek to where we left off") and test again?
 >=20
 > This:
 [...]
 > doesn't seem to work:
 
 This does (with and without relocating the fseek() block first):
 
 diff --git a/usr.bin/fetch/fetch.c b/usr.bin/fetch/fetch.c
 index a165501..6c5ece5 100644
 --- a/usr.bin/fetch/fetch.c
 +++ b/usr.bin/fetch/fetch.c
 @@ -540,7 +540,7 @@ fetch(char *URL, const char *path)
  				goto failure;
  			}
  			/* we got it, open local file */
 -			if ((of =3D fopen(path, "a")) =3D=3D NULL) {
 +			if ((of =3D fopen(path, "r+")) =3D=3D NULL) {
  				warn("%s: fopen()", path);
  				goto failure;
  			}
 
 Fabian
 
 --Sig_/VK+iB09RJd20nb=+mFhcLyA
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (FreeBSD)
 
 iEYEARECAAYFAk59vEAACgkQSMVSH78upWOsSwCgipsbMcwKZ3kBRjD/44dO+8F1
 ZwIAn14Fjv1f2MRIf4DFDe1Wrhz7j/m5
 =IApQ
 -----END PGP SIGNATURE-----
 
 --Sig_/VK+iB09RJd20nb=+mFhcLyA--

From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Fabian Keil <fk@fabiankeil.de>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/117277: [patch] fetch(1): fetch's resume mode doesn't verify that it actually got partial content
Date: Sat, 24 Sep 2011 13:45:32 +0200

 Fabian Keil <fk@fabiankeil.de> writes:
 > I think this is because the file is opened in append mode.
 > Quoting fopen(3):
 > |     ``a''   Open for writing.  The file is created if it does not exist=
 .  The
 > |             stream is positioned at the end of the file.  Subsequent wr=
 ites
 > |             to the file will always end up at the then current end of f=
 ile,
 > |             irrespective of any intervening fseek(3) or similar.
 >
 > I guess this means the fseek() had no effect in the previous
 > location either, although I didn't test it.
 
 Doh!  I had forgotten that "a" broke fseek.  Thank you.
 
 DES
 --=20
 Dag-Erling Sm=C3=B8rgrav - des@des.no

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/117277: commit references a PR
Date: Tue, 27 Sep 2011 15:57:22 +0000 (UTC)

 Author: des
 Date: Tue Sep 27 15:57:13 2011
 New Revision: 225800
 URL: http://svn.freebsd.org/changeset/base/225800
 
 Log:
   Followup to r225599: the fseek() was a no-op since the file was opened
   in append mode.  Open it in read-write mode instead.  Also move the
   fseek up one level to cover the (unlikely but not impossible) case where
   the server accepts ranges but does not send a Content-Size header.
   
   PR:		bin/117277
   MFC after:	3 weeks
 
 Modified:
   head/usr.bin/fetch/fetch.c
 
 Modified: head/usr.bin/fetch/fetch.c
 ==============================================================================
 --- head/usr.bin/fetch/fetch.c	Tue Sep 27 15:08:59 2011	(r225799)
 +++ head/usr.bin/fetch/fetch.c	Tue Sep 27 15:57:13 2011	(r225800)
 @@ -540,7 +540,7 @@ fetch(char *URL, const char *path)
  				goto failure;
  			}
  			/* we got it, open local file */
 -			if ((of = fopen(path, "a")) == NULL) {
 +			if ((of = fopen(path, "r+")) == NULL) {
  				warn("%s: fopen()", path);
  				goto failure;
  			}
 @@ -559,13 +559,13 @@ fetch(char *URL, const char *path)
  				sb = nsb;
  				/* picked up again later */
  			}
 -			/* seek to where we left off */
 -			if (of != NULL && fseek(of, url->offset, SEEK_SET) != 0) {
 -				warn("%s: fseek()", path);
 -				fclose(of);
 -				of = NULL;
 -				/* picked up again later */
 -			}
 +		}
 +		/* seek to where we left off */
 +		if (of != NULL && fseek(of, url->offset, SEEK_SET) != 0) {
 +			warn("%s: fseek()", path);
 +			fclose(of);
 +			of = NULL;
 +			/* picked up again later */
  		}
  	} else if (m_flag && sb.st_size != -1) {
  		/* mirror mode, local file exists */
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/117277: commit references a PR
Date: Wed, 19 Oct 2011 12:14:24 +0000 (UTC)

 Author: des
 Date: Wed Oct 19 12:14:14 2011
 New Revision: 226540
 URL: http://svn.freebsd.org/changeset/base/226540
 
 Log:
   MFH r225599,225800,225805: improve handling of resumed http transfers
   
   PR:		bin/117277
 
 Modified:
   stable/8/usr.bin/fetch/fetch.c
 Directory Properties:
   stable/8/usr.bin/fetch/   (props changed)
 
 Modified: stable/8/usr.bin/fetch/fetch.c
 ==============================================================================
 --- stable/8/usr.bin/fetch/fetch.c	Wed Oct 19 11:49:14 2011	(r226539)
 +++ stable/8/usr.bin/fetch/fetch.c	Wed Oct 19 12:14:14 2011	(r226540)
 @@ -522,6 +522,12 @@ fetch(char *URL, const char *path)
  				    "does not match remote", path);
  				goto failure_keep;
  			}
 +		} else if (url->offset > sb.st_size) {
 +			/* gap between what we asked for and what we got */
 +			warnx("%s: gap in resume mode", URL);
 +			fclose(of);
 +			of = NULL;
 +			/* picked up again later */
  		} else if (us.size != -1) {
  			if (us.size == sb.st_size)
  				/* nothing to do */
 @@ -534,7 +540,7 @@ fetch(char *URL, const char *path)
  				goto failure;
  			}
  			/* we got it, open local file */
 -			if ((of = fopen(path, "a")) == NULL) {
 +			if ((of = fopen(path, "r+")) == NULL) {
  				warn("%s: fopen()", path);
  				goto failure;
  			}
 @@ -551,8 +557,16 @@ fetch(char *URL, const char *path)
  				fclose(of);
  				of = NULL;
  				sb = nsb;
 +				/* picked up again later */
  			}
  		}
 +		/* seek to where we left off */
 +		if (of != NULL && fseeko(of, url->offset, SEEK_SET) != 0) {
 +			warn("%s: fseeko()", path);
 +			fclose(of);
 +			of = NULL;
 +			/* picked up again later */
 +		}
  	} else if (m_flag && sb.st_size != -1) {
  		/* mirror mode, local file exists */
  		if (sb.st_size == us.size && sb.st_mtime == us.mtime)
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: des 
State-Changed-When: Mon Nov 5 13:03:34 UTC 2012 
State-Changed-Why:  
fixed 

http://www.freebsd.org/cgi/query-pr.cgi?pr=117277 
>Unformatted:
