From owner-freebsd-bugs  Fri Jul  7  0:30: 7 2000
Delivered-To: freebsd-bugs@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id EA2F137BDF7
	for <freebsd-bugs@FreeBSD.org>; Fri,  7 Jul 2000 00:30:01 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id AAA97811;
	Fri, 7 Jul 2000 00:30:01 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Received: from cr280808-a.crdva1.bc.wave.home.com (cr280808-a.crdva1.bc.wave.home.com [24.113.241.196])
	by hub.freebsd.org (Postfix) with SMTP id F3D7137BDC9
	for <FreeBSD-gnats-submit@freebsd.org>; Fri,  7 Jul 2000 00:25:48 -0700 (PDT)
	(envelope-from lyonsm@cr280808-a.crdva1.bc.wave.home.com)
Received: (qmail 926 invoked by uid 0); 6 Jul 2000 23:44:32 -0000
Message-Id: <20000706234432.925.qmail@cr280808-a.crdva1.bc.wave.home.com>
Date: 6 Jul 2000 23:44:32 +0000
From: lyonsm@netbistro.com
Reply-To: ml-dyn-bsdpr@netbistro.com
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: bin/19748: fetch -o clobbers special files
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         19748
>Category:       bin
>Synopsis:       fetch -o will unlink special files
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jul 07 00:30:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     M Lyons
>Release:        FreeBSD 4.0-RELEASE i386
>Organization:
>Environment:


>Description:

(This is arguably a change-request and not a sw-bug.)

In some circumstances, fetch -o will unlink the target file if a transfer
fails.  It's true that this behaviour can be suppressed with the -R
switch; however, fetch should probably never unlink special files or files
it didn't create (or other people who use fetch -o/dev/null in a script
might find themselves wondering why /dev/null keeps disappearing. :)

>How-To-Repeat:

As root, fetch an unreachable address to /dev/null, and then kill with
SIGINT before it times out:

  # cp -Rp /dev/null /tmp/mynull
  # fetch -o/tmp/mynull http://1.2.3.4/foo
  (wait a few sec, then hit CTRL-C)
  # ls -l /tmp/mynull
  (it's gone!)

>Fix:

The following patch to src/usr.bin/fetch/util.c makes fetch
more careful about unlinking special files.  A better fix might
be to have fetch decline to unlink files it didn't create.


*** util.c.orig	Thu Jul  6 23:08:10 2000
--- util.c	Thu Jul  6 23:23:53 2000
***************
*** 29,36 ****
--- 29,37 ----
   * $FreeBSD: src/usr.bin/fetch/util.c,v 1.7 1999/08/28 01:00:52 peter Exp $
   */
  
  #include <sys/types.h>
+ #include <sys/stat.h>
  
  #include <ctype.h>
  #include <err.h>
  #include <errno.h>
***************
*** 104,117 ****
  }
  
  /*
   * Delete the file when exiting on error, if it is not `precious'.
   */
  void
  rm(struct fetch_state *fs)
  {
  	if (!(fs->fs_outputfile[0] == '-' && fs->fs_outputfile[1] == '\0')) {
! 		if (!fs->fs_restart && !fs->fs_mirror && !fs->fs_precious)
  			unlink(fs->fs_outputfile);
  		else
  			adjmodtime(fs);
  	}
--- 105,126 ----
  }
  
  /*
   * Delete the file when exiting on error, if it is not `precious'.
+  * Files which exist and are not plain files are automatically considered
+  * precious.
   */
  void
  rm(struct fetch_state *fs)
  {
+ 	int precious = fs->fs_precious;
+ 	struct stat sb;
+ 
+ 	if(lstat(fs->fs_outputfile, &sb)) return;
+ 	if((sb.st_mode & S_IFMT) != S_IFREG) precious = 1;
+ 
  	if (!(fs->fs_outputfile[0] == '-' && fs->fs_outputfile[1] == '\0')) {
! 		if (!fs->fs_restart && !fs->fs_mirror && !precious)
  			unlink(fs->fs_outputfile);
  		else
  			adjmodtime(fs);
  	}


>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message