HDTenEightyP/NetNews huggingface dataset:
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: GNU su doesn't restrict root access?  Why?
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Mon, 12 Oct 1992 05:06:23 GMT

>From the su man page (shellutils 1.7):

     This program does not support a "wheel group" that	restricts
     who can su	to super-user accounts,	because	that is	fascist.

Fascist?  My own opinion is that restricting superuser access is a valid
security measure; can you give me a single valid reason that non-wheel (or
group 'root', on our system) users should be allowed to su to root?

On our system, staff members have more cryptic passwords than do most
users, so that would-be intruders have to guess two difficult passwords to
break root.  If they could go through a normal user's account, their path
would be somewhat easier.

Assuming that only system managers will be allowed to su to root, why not
code the restriction in su, rather than depending on the security of the
password?

Jason Merrill
jason@jarthur.claremont.edu



Newsgroups: gnu.utils.bug
From: slester@vetmed.wsu.edu (Samuel M. Lester)
Subject: Gnutar 1.11.1 and TapeLength
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 8 Oct 1992 21:53:27 GMT

	
                                                  
                           Sam Lester              
                     
	
Mailer: Elm [revision: 70.30]



 Hi,

   this what I think is a bug in gnu tar 1.11.1 and the -L option for
   tapelenght.  I work on HP9000/720 HP9000/817 HP9000/425e and Next.
   On the 817s I have had a problem with tar and -L 24000000 byte lenght.
   I was using the level-0 script modified by me to include -L.  The 
   program wrote (a very little) and kept prompting me for the next 
   volume.  When I took the -L out it worked fine.  Anyhow see what
   you can do. Maybe ints are too small for 2.4 gbTapes
   Thanks, 


   Sam Lester
   slester@vetmed.wsu.edu
   509-335-0812

Newsgroups: gnu.utils.bug
From: schulte@thp.uni-koeln.DE
Subject: '+verify'-bug in tar 1.11.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 21:39:00 GMT

Machine:  SPARCstation II
OS:       SunOS 4.1.1
Compiler: gcc 2.2.1

Description: When trying to verify a tar-archive written to tape,
I get an I/O-error, although the archive is correctly written.

Example:

>tar cWf /dev/rst0 testfile
tar: read error on /dev/rst0 : I/O error
>tar tf /dev/rst0
testfile
>

Comment: The problem seems to fixed, if MTBSF is replace by MTNBSF in
line 465 of diffarch.c.

Martin

Newsgroups: gnu.utils.bug
From: marc@cam.org (Marc Boucher)
Subject: GNU sed
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 11 Oct 1992 14:27:06 GMT

GNU sed-1.09 is a source of many headaches (incompatibilities) if built as
delivered.

I would suggest a new release with regex.[ch] updated from regex-0.11
and the following change:


--- 1.1	1992/10/11 22:17:02
+++ sed.c	1992/10/11 22:17:24
@@ -327,7 +327,7 @@
 	struct sed_label *go,*lbl;
 
 	/* see regex.h */
-	re_set_syntax (RE_INTERVALS | RE_NO_BK_BRACES);
+	re_set_syntax (RE_SYNTAX_SED);
 
 
 	myname=argv[0];


best regards,
marc.

Newsgroups: gnu.utils.bug
From: noel@ac.wfunet.wfu.edu (Noel Hunter)
Subject: problem with HP-UX
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 14:32:32 GMT

Thanks for GNU finger.  It works surprisingly well, considering the
nature of HP-UX.  I have encountered one serious problem:

   * The Finger version and where you obtained the distribution
   Source: ftp.uu.net:packages/gnu/finger

   * Your hardware
   Hewlett-Packard 9000 Model 852

   * Operating system
   HP-UX 8.0

   * C Compiler used
   HP-UX C compiler

   * Your network configuration; don't forget to mention what
     hardware, operating systems, and C compilers are used on each
     node where the bug manifests itself.
   Currently, stand-alone for finger

The problem:

When fingering for a non-existent user (not in password file, alias, or
anywhere else, the in.fingerd server hangs, leaving a process like
this:

    root 22285   169 88 09:21:01 ?        0:08 finger

The process never finishes, and the remote user never gets a response.
The same thing happens locally with the GNU finger client on the server.

When the user is found, finger works normally.  If you are interested in
working on this program, I will be happy to send any files, or to provide
you with a login on our machine.

Regards,
Noel Hunter

* Noel Hunter,  Academic Computing Support Coordinator,  Wake Forest Univ.  *
* noel@wfu.edu TEL:(919) 759-5261  MAIL:PO Box 7408 Winston-Salem, NC 27109 *



Newsgroups: gnu.utils.bug
From: neal@ctd.COMsat.COM (Neal Becker)
Subject: finger-1.36 minor bug on hpxu-id
Organization: COMSAT Labs
Distribution: gnu
Date: Tue, 13 Oct 1992 14:33:19 GMT

Thanks for finger-1.36!  Installation was a lot easier than 1.35.  One
minor problem:

On hpux 8.07 finger shows entries for terminal "co" (console, I guess)
which all show idle time of 24 years!  Anyone know why?

Another minor install problem.  make server or make client insists on
recompiling things.  This can cause nasty root NFS access problems, if
your source directory is NFS mounted, since installation may require
root privlege.  It would be nicer to use a more traditional approach,
so that make would build all sources, and make server would only
install without modifying the source directory.


BTW - everyone knows -lPW causes problems with HPUX (/lib/libPW.a
contains definitions of some stuff you don't want along with alloca).
Some gnu installs suggest extracting alloca and making a
/usr/local/lib/liballoca.a.  I have been using this approach.
Unfortunately, gnu configure doesn't know about this.  I suggest that
configure should look for liballoca.a first, then libPW.a.  The
alternative approach (used by finger-1.36) is:

	ld ... -lPW -lc -lPW

Unfortunately, my experience is that this is not only silly, it also
doesn't always work.  I vote for supporting liballoca instead.

Newsgroups: gnu.utils.bug
From: qralston@cislabs.pitt.EDU (James Ralston Crawford)
Subject: comps/complaints/problems with GNU finger
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 19:16:06 GMT

obtained from:	prep.ai.mit.edu
version:	1.35
hardware:	Sun-4/670MP, Sun-4/50, Sun-4/40
OS:		SunOS 4.1.2 (on all machines)
C compiler:	gcc -O2 (on all machines)

	Summary: configuring is easy.  Make process has some bugs.
Installing is a nightmare.  Once installed, though, it works like a
charm.

	In the installation instructions, put the instructions for
changing config.h and fingerpaths.h BEFORE you tell them to run
configure.

	The `configure` step is rather convenient.

	Make runs into problems.  You're assuming X11 include files
are in something like /usr/X11R5/include.  This is wrong for most
systems.  Either ask, or figure it out.  You're also assuming certain
X header files are there that *aren't* there.  (At least not for
X11R5.)  Had to leave out the X11 stuff.  Other than that, make was
smooth.

	Make server blows up.  First of all, in src/.fingerdir, you
quote (") the directory.  The shell doesn't evaluate this, and ends up
testing (and trying to mkdir) \"/usr/local/whatever\".

	Make server doesn't do anything to /etc/services.

	Make server doesn't do anything to /etc/inetd.conf

	Make server doesn't do anything to /etc/rc* to add the
fingerd.

	Ditto for make client.

	Not only does the automation fail, YOU DO NOT SAY WHAT NEEDS
TO BE MODIFIED IN EACH OF THESE FILES.  I figured out what to put in
each file, but I suspect a lot of people wouldn't.  Spell it out, in
big letters.

	I had to go in and create all of the files that had to be in
finderd myself.  I had to figure out what to create from
fingerpaths.h.

	Don't put fingerd in bindir; put it in etcdir.  There's no
reason to "leave it out in the open" for everyone to bang on.

	Say in the docs that fingerd only runs on the SERVER.  This is
becomes obvious if you try to start it on a client, but it's unclear
without doing this.

	What does TTYLOCFILE do?

	Regards,

James

-- 
James Ralston Crawford \ Advanced Technology Lab                   The
qralston@cislabs.pitt.edu \ qralston@pittvms.bitnet                 Phantom
"Pitiful creature of darkness \ What kind of life have you known"  - of the
"God give me courage to show you \ You are not alone"                 Opera

Newsgroups: gnu.utils.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Error in standards.texi
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Mon, 12 Oct 1992 06:55:46 GMT

The 'releases' section of standards.texi says:

-----
   Try to make sure that all the file names will be unique on MS-DOG. 
A name on MS-DOG consists of up to 9 characters, optionally followed
by a period and up to three characters.
-----

This should, in fact, be _8_ characters, followed by a period and three
more.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.utils.bug
From: dpt@msri.org (Dylan Thurston)
Subject: Problems on Suns & Irises
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 15:05:56 GMT

While installing the latest distribution of GNU Finger 1.36, I have
encountered two problems so far:

On a SUN 670 MP running SUN OS release 4.1.2, the header files appear
to be non-ANSI as distributed: in particular, the declarations of
abort and exit are wrong (the return codes are declared as 'int').
The configure script does not notice this and attempts to use them.
Since I have gcc installed, the configure script attempted to use it;
and gcc complained about this deficiency.  (I am curious about this
feature of gcc: I wasn't aware that any functions were built in and
could not be overridden.  Is there a way to turn this off, or at least
make it compile the file anyway (ignoring the incorrect declaration)?)
(As a workaround I used the standard C compiler, since I didn't know
how to turn off the feature of gcc, didn't notice the DSTDC_HEADERS
option, and didn't want to modify the header files.  Sorry.)

On an IRIS Indigo (System V release 4.0.2), the standard C compiler
seems to be remarkably pedantic.  It gives the following message
(while working in the lib directory):

accom: Error: packet.c, line 521: static function declaration in inner block is illegal (ANSI C 3.5.1)
         static int read_component ();
       ------------------------------^

It gives the same error again, in in.fingerd.c.  Also, in os.c it
whines that 'text following '#endif' violates ANSI standard'.

(I lied, here's another problem.)  On the IRIS, alloca is defined ONLY
in the header file.  Thus, when lib/bitmap.c, lib/packet.c, and
src/finger.c try to use alloca without declaring it, it doesn't
working.  (From the top of getopt.c, it seems likely they'll have more
trouble under AIX as well.)  (Actually, this seems like it's a problem
in getopt.c as well.  I'll send a separate bug report on that.)

And one more comment--the message when finger can't find the port to
connect to is singularly unhelpful.  Is there any way to make it
better?



Newsgroups: gnu.utils.bug
From: dkarr@dopey.sierra.COM (David Karr)
Subject: Re: Variable redefinition using += in GNU Make...
Organization: Sierra Geophysics, Inc.
Distribution: gnu
Date: Wed, 7 Oct 1992 16:55:39 GMT

In article <9210052258.AA01624@pepper.ncd.com> mellon@pepper.UUCP (Ted Lemon) writes:

> I'm trying to use GNU Make on some of our makefiles internally, but
> I find that we use a feature present in 4.3-Tahoe and SunOS make,
> which is that you can add stuff to the end of a variable definition by
> using a += operator; e.g.,
> 
> FOO = bar
> FOO += baz
> 
> Would result in foo being set to ``bar baz''.   I notice that this
> functionality is implemented differently in GNU make - a := operator
> has been introduced which evaluates the RHS before assigning to the
> LHS (I'm not entirely clear on how this works, but I'm sure it will be
> evident when I spend a little time playing with it).
> 
> The problem is this: I am now stuck with having to choose which
> implementation to support - GNU Make doesn't support the += construct,
> and SunOS/BSD Make doesn't support the := construct.   Does anybody
> have any plans to do anything about this, or am I putting my foot in a
> religious debate by bringing this up?
> 
> 			       _MelloN_

Seems pretty clear to me.  You can easily port Gnu to any other system, but
you can't port Sun Make to any other system.  I find Gnu make is much more
functional than Sun's make.
--
David M. Karr
Sierra Geophysics, Inc.
ARPA: dkarr@sierra.com, UUNET: uunet!sgihbtn!dkarr
Phone: (206) 822-5200 (343)

Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: Re: diff2.0 bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 03:31:10 GMT

brennan@baker.ds.boeing.COM (Michael D Brennan) writes:

	The following setup with diff2.0 core dumps:

	GNU diff version 2.0
	compiled gcc2.2.2 -O2 -g  (does not happen -g only)

	sun sparc station ipc, os4.1.1

A bug causes GCC 2.2.2 (sparc, with the -O2 option) to generate
incorrect code for the diag routine of GNU diff.
To work around the problem, compile diff with plain -O instead.
This bug was reported to bug-gcc in late July,
and I think it will be fixed when GCC 2.3 comes out.

Newsgroups: gnu.utils.bug
From: cagney@cs.adelaide.EDU.AU (Andrew Cagney - aka Noid)
Subject: [binutils-2.0/bfd/reloc.c] Make clear what reloc_funcs should do...
Reply-To: cagney@cs.adelaide.edu.au (Andrew Cagney - aka Noid)
Organization: Comp Sci, Uni of Adelaide, Australia
Distribution: gnu
Date: Thu, 15 Oct 1992 05:03:45 GMT

[This is a cosmetic change]

In binutils-2.0/bfd/reloc.c:bfd_perform_relocation() the following code
sequence occures:

		if symbol undefined
			flag = bfd_reloc_undefined

		if have special_relocation_funciton
			cont = special_relocation_function()
			if cont != continue
				return cont

		<rest of relocation code>

The patch below rearanges this code to be:

		if have special_relocation_funciton
			cont = special_relocation_function()
			if cont != continue
				return cont

		if symbol undefined
			flag = bfd_reloc_undefined

		<rest of relocation code>

Which makes it more obivous to the user that a special_relocation_function()
must check (and possibly return the corresponding status) for undefined
symbols.

					Andrew Cagney


cagney@winnie% rcsdiff -c bfd/reloc.c
===================================================================
RCS file: bfd/RCS/reloc.c,v
retrieving revision 1.1
diff -c -r1.1 bfd/reloc.c
*** /tmp/RCSAa15969     Thu Oct 15 11:00:13 1992
--- bfd/reloc.c Thu Oct 15 10:44:36 1992
***************
*** 452,461 ****
         
    }
  
-   if ((symbol->section == &bfd_und_section) && output_bfd == (bfd *)NULL) {
-     flag = bfd_reloc_undefined;
-   }
- 
    if (howto->special_function) {
      bfd_reloc_status_type cont;
      cont = howto->special_function(abfd,
--- 452,457 ----
***************
*** 465,470 ****
--- 461,470 ----
                                   input_section,
                                   output_bfd);
      if (cont != bfd_reloc_continue) return cont;
+   }
+ 
+   if ((symbol->section == &bfd_und_section) && output_bfd == (bfd *)NULL) {
+     flag = bfd_reloc_undefined;
    }
  
    /* 




Xref: sparky gnu.utils.bug:1786 gnu.gcc.bug:2446 gnu.emacs.bug:1348
From: phr@napa.telebit.com (Paul Rubin)
Newsgroups: gnu.utils.bug,gnu.gcc.bug,gnu.emacs.bug
Subject: documentation suggestion
Date: 8 Oct 92 23:13:51 GMT
Followup-To: poster
To: bug-gnu-utils@prep.ai.mit.edu, bug-gnu-emacs@prep.ai.mit.edu,
        bug-gcc@prep.ai.mit.edu

I urge that it become an official policy that *every* GNU manual
should, in its Top node, prominently state the version number of the
program that it documents (e.g. Emacs version 18.58, not just version 18).
I have no convenient way to tell right now whether the documents in
the Info tree I'm using are up to date.  Printed manuals should also
prominently state the version number on the title page, but this isn't
usually such a bad problem.
Newsgroups: gnu.utils.bug
From: halvers@sol.CRd.ge.COM (peter c halverson)
Subject: bzrto dumps core generating MF output
Reply-To: Pete Halverson <halverson@crd.ge.com>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 16:22:43 GMT

CONFIGURATION

GNU fontutils version 0.5
SparcStation 2
SunOS 4.1.2
OpenWindows 3.0, olwm

DESCRIPTION

Invoking bzrto with the following options
  
   % bzrto -verbose -metafont gbbb30b -output=gbbb30B

dumps core with a segmentation violation when writing the Metafont
epilogue.  The failure occurs in the function "output_ligtable" while
writing ligature information, caused by a pointer dereference that occurs
before the data is tested for validity (in a local variable
initialization).

SUGGESTED FIX

Making the following change to bzrto/metafont.c corrects the problem:

bzrto/metafont.c
415c415
<       tfm_char_type *c;
---
>       tfm_char_type *c = CHAR_TFM_INFO (*(chars[code]));
422,424c422
< 
<       c = CHAR_TFM_INFO (*(chars[code]));
< 
---
>       


Newsgroups: gnu.utils.bug
From: brianw@pki-nbg.PHilips.DE (Brian Wallis)
Subject: Bug in gmake 3.60?
Summary: Viewpaths don't work as expected
Keywords: gmake 3.60 VPATH viewpath
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 15:55:08 GMT

I have come across a problem with VPATH as implemented by gmake 3.60.
The problem is summerized below.

Two directories...

	/tmp/src1:
	total 6
	-rw-rw-r--   1 brianw   ln1           40 Oct  9 14:56 test.c
	-rw-rw-r--   1 brianw   ln1         1384 Oct  9 14:57 test.o

	/tmp/src2:
	total 36
	-rw-rw-r--   1 brianw   ln1           40 Oct  9 14:55 Makefile
	-rwxrwxr-x   1 brianw   ln1        16384 Oct  9 14:58 test
	-rw-rw-r--   1 brianw   ln1           40 Oct  9 16:58 test.c

Makefile is:


	VPATH= /tmp/src2:/tmp/src1
	test: test.o

and I compile in /tmp/src2 with...

	$ gmake
	gmake: `test' is up to date.

Which, as can be seen, is not true.

src2/test.c is much newer that src2/test and the dependancies are that
test.c should cause the updating of test.o and test.o updates test.

The problem seems to be that once gmake finds a file in the
dependancy list it locks itself into that directory and doesn't use
the viewpath anymore.

I think it should find test.o (in src1) and then discover that test.o is
older that test.c (in src2). Then remake test.o, but make it
in src2, not replace the one in src1 (to which, in the real case here,
I do not have access)

So is it a bug, or do I misunderstand the use of a viewpath?

brian wallis...

Newsgroups: gnu.utils.bug
From: rwright@dhostwo.convex.com (Randy Wright)
Subject: tar 1.11.1 enhancement idea
Reply-To: rwright@convex.com
Organization: Convex Computer Corporation
Distribution: gnu
Date: Mon, 12 Oct 1992 15:15:41 GMT

Hello again!

It seems to me that when extracting files from an archive with the
-S/--sparse flag,  it would be a nice feature to be able to create the
files sparsely where appropriate, regardless of whether the archive was
created with the -S/--sparse flag.  I have in fact made such an
enhancement here that I'd be happy to submit if there's interest at
your end.  All that's necessary is to be willing to trade a bit of
processor time for potential disk space savings - we see if each
block of extracted data is composed entirely of zero's and lseek
the output file as appropriate if so.   Blocks are defined,
for BSD-derived systems, by the blocksize of the target file system.
(I guess the V7/old USG blocksize should be a fixed 512, right?)

Let me know if you're interested in this enhancement - I can send
it along if so.

-- 
Randy Wright			Usmail:	Convex Computers
Phone: (214) 497-4868			3000 Waterview Pky. M/S DV4
Email:	rwright@convex.com		P.O. Box 833851
					Richardson, TX  75083-3851

Newsgroups: gnu.utils.bug
From: rrh@tera.com (Robert R. Henry)
Subject: bad file names output by binutils2.0: objdump (resending... again)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 17:03:22 GMT

When running objdump from binutils2.0 host=sparc, target=m68k,
on an executable built using the glibc1.05,
one finds this kind of output:

on a simple file

  test:     file format a.out-sunos-big

  Disassembly of section .text:
  .....stuff deleted}
  ./libgcc2.csysdeps/unix/bsd/sun/m68k/start.c:30
  00002098 (_start1+)006e rts

The file name that is being printed is bogus.
libgcc2.c comes from gcc2.2.2,
whereas sydeps/unix/bsd/sun/m68k/start.c comes from glibc1.05.
Looks like some string concatenation problem.

Newsgroups: gnu.utils.bug
From: bjornw@colargol.ai.mit.EDU (Bjoern Wennberg)
Subject: Question about id from shellutil-1.7
Organization: Colargol, Trondheim College of Engineering
Distribution: gnu
Date: Thu, 15 Oct 1992 13:18:44 GMT

ID FROM SHELLUTIL-1.7
Hi!

I have a simple question about id:

If I write 
$id bjornw
uid=1175(bjornw) gid=120(student) groups=160(X)
$newgrp X
$id bjornw
uid=1175(bjornw) gid=120(student) groups=160(X)

Is this the right behaviour of id or should it produce this output:
uid=1175(bjornw) gid=160(X) groups=120(student)
since I'm now group 'X' rather than group 'student' ?

bjornw>
--
The sooner all the animals are dead, the sooner we'll find all their money.

Newsgroups: gnu.utils.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Finger 1.36 doesn't support -m or -p properly
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Sat, 10 Oct 1992 09:59:44 GMT

On our system, staff members have first name accounts, which can cause some
havoc when dealing with finger; if someone types 'finger jason', they will
get a listing of all the Jason's on the system.  If they only want to look
at my entry, they can type 'finger -m jason'.  This is a very useful
option, but 1.36 treats it the same as -l.

Similarly, -p tells finger not to display .plan or .project files, whereas
GNU finger wants it to specify the port number.

Are these options not standard?  They are present in SunOS 4.1.2...

There are various other options missing as well.

--
Jason Merrill

Newsgroups: gnu.utils.bug
From: stuart@oasys.dt.navy.mil
Subject: gnu tar 1.11.1 - owner/group not preserved for directories on extract.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 8 Oct 1992 11:55:19 GMT

Utility:	gnu tar 1.11.1
System:		Sequent Symmetry S27
OS: 		dynix 3.0.17.9
Source:		ftp.uu.net:packages/gnu/tar-1.11.1.tar.Z

When extracting files from an archive as root (tar xvpf), the owner
and group are not preserved on directories.  This makes it impossible
to use gnu tar to copy a directory subtree to another location:

	cd /foo ; tar cvf - . | (cd /bar; tar xvpf -)

NOTE:  If the -m flag is included to the tar extract command (tar
xvpmf), owner & group are preserved, but modification times aren't.

Included below is a patch which I think will fix the problem.

-stuart

--
Stuart Pearlman                                 stuart@oasys.dt.navy.mil
Trandes Corporation                             +1 301 459 0200
On-Contract-To: David Taylor Research Center    +1 301 227 1428
---------------------------------------------------------------------------
*** /tmp/,RCSt1013898	Thu Oct  8 15:37:32 1992
--- extract.c	Thu Oct  8 15:33:12 1992
***************
*** 652,657
  
  		if (f_modified)
  		  goto set_filestat;
  		tmp = (struct saved_dir_info *) malloc (sizeof (struct saved_dir_info));
  		tmp->path = malloc (strlen (skipcrud + current_file_name) + 1);
  		strcpy (tmp->path, skipcrud + current_file_name);

--- 652,667 -----
  
  		if (f_modified)
  		  goto set_filestat;
+ 
+                 if (we_are_root || f_do_chown) {
+                         if (chown(skipcrud + current_file_name,
+                                   hstat.st_uid, hstat.st_gid) < 0) {
+                           msg_perror("cannot chown file %s to uid %d gid %d",
+                                      skipcrud + current_file_name,
+                                      hstat.st_uid,hstat.st_gid);
+ 			}
+ 		}
+ 
  		tmp = (struct saved_dir_info *) malloc (sizeof (struct saved_dir_info));
  		tmp->path = malloc (strlen (skipcrud + current_file_name) + 1);
  		strcpy (tmp->path, skipcrud + current_file_name);


Newsgroups: gnu.utils.bug