Bug 23719

Summary:	New fetch(1) doesn't pick up FTP_LOGIN env var (older libftpio-linked version did). Also fetch's -R option is either buggy or misleading.
Product:	Base System	Reporter:	sketchy <sketchy>
Component:	bin	Assignee:	Dag-Erling Smørgrav <des>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	4.2-RELEASE
Hardware:	Any
OS:	Any

Description sketchy 2000-12-21 19:10:01 UTC

	Versions of fetch(1) linked against libftpio (2.x/3.x) honour an
	FTP_LOGIN variable, whereas newer versions using libfetch do not.
	This can create interopable problems with scripts when upgrading
	to newer releases.

	fetch(1)'s -R option also malfunctions with respect to existing
	files which are being resumed - if fetch cannot resume the transfer,
	it should not unlink the file and start from the beginning.  Either
	that or the manpage should be updated to clarify the situation.

	This was noticed when trying to resume the last 1Gb or so of a
	7.6Gb transfer over a 2MB link.  Needless to say finding out the
	6Gb or so of data already transferred had been deleted wasn't fun :)

How-To-Repeat: 
	fetch a large file, interrupt it midway.
	Attempt to resume the transfer with "fetch -apRr"

	If the server cannot establish a resume transfer, fetch will
	delete the local file and start the transfer from the beginning.

Comment 1 des 2000-12-22 09:17:52 UTC

Jonathan Perkin <sketchy@netcraft.com> writes:
> 	Versions of fetch(1) linked against libftpio (2.x/3.x) honour an
> 	FTP_LOGIN variable, whereas newer versions using libfetch do not.
> 	This can create interopable problems with scripts when upgrading
> 	to newer releases.

Try the following patch:

Index: ftp.c
===================================================================
RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v
retrieving revision 1.56
diff -u -r1.56 ftp.c
--- ftp.c	2000/12/06 09:23:27	1.56
+++ ftp.c	2000/12/21 19:31:38
@@ -762,6 +762,8 @@
     /* send user name and password */
     user = url->user;
     if (!user || !*user)
+	user = getenv("FTP_LOGIN");
+    if (!user || !*user)
 	user = FTP_ANONYMOUS_USER;
     if (purl && url->port == _fetch_default_port(url->scheme))
 	e = _ftp_cmd(cd, "USER %s@%s", user, url->host);

> 	fetch(1)'s -R option also malfunctions with respect to existing
> 	files which are being resumed - if fetch cannot resume the transfer,
> 	it should not unlink the file and start from the beginning.  Either
> 	that or the manpage should be updated to clarify the situation.

This only happens if the local and remote modification times do not
match, which means that the remote file changed or fetch was killed
hard (a normal INTR will abort the transfer, but still set the mtime
of the local file to that of the remote file). Try the following
patch:

Index: fetch.c
===================================================================
RCS file: /home/ncvs/src/usr.bin/fetch/fetch.c,v
retrieving revision 1.24
diff -u -r1.24 fetch.c
--- fetch.c	2000/12/13 11:26:27	1.24
+++ fetch.c	2000/12/22 09:12:17
@@ -322,6 +322,11 @@
 	if (!F_flag && us.mtime && sb.st_mtime != us.mtime) {
 	    /* no match! have to refetch */
 	    fclose(f);
+	    /* if precious, warn the user and give up */
+	    if (R_flag) {
+		warnx("%s: local and remote modification times do not match");
+		goto failure_keep;
+	    }
 	    url->offset = 0;
 	    if ((f = fetchXGet(url, &us, flags)) == NULL) {
 		warnx("%s: %s", path, fetchLastErrString);

DES
-- 
Dag-Erling Smorgrav - des@ofug.org

Comment 2 Dag-Erling Smørgrav freebsd_committer

2000-12-22 09:18:05 UTC

State Changed
From-To: open->feedback

Patches have been sent to originator.

Comment 3 Dag-Erling Smørgrav freebsd_committer

2000-12-22 09:18:05 UTC

Responsible Changed
From-To: freebsd-bugs->des

I maintain libfetch and fetch.

Comment 4 Dag-Erling Smørgrav freebsd_committer

2000-12-27 16:42:46 UTC

State Changed
From-To: feedback->closed

Fixed in -CURRENT and -STABLE.