Re: [Bug-wget] Recursive wget: change in handling of file permissions?

2011-10-04 Thread Giuseppe Scrivano
Hi Micah,
Micah Cowan mi...@cowan.name writes:

 So, from where I'm sitting, it looks like --preserve-permissions was an
 implemented feature for two major releases (1.10 and 1.11 series), and
 has now been missing from the last two major releases (1.12 and 1.13).
 Probably, it should be reinstated, and documentation added, to restore
 previous behavior.

 Giuseppe?

thanks for the detailed analysis and sorry for my late reply.  If this
is the case, then I think --preserve-permissions has to be restored as
it used to work in the 1.10.* series.

Cheers,
Giuseppe



Re: [Bug-wget] Recursive wget: change in handling of file permissions?

2011-10-03 Thread Metzler, Chris

Thanks for the explanation of what's going on.  Ugh -- I wonder why that
change was made?  It seems odd to me, since there was already the
capability to force local permissions to be those of the remote file
(via the --preserve-permissions switch, as you noted), so you could
already do that if you wanted; now you can *only* do that.

Anyway, thanks again!

-c


Chris Metzler
Naval Research Laboratory, Code 7669
202-767-6166
christopher.metz...@nrl.navy.mil
-Original Message-
From: Steven M. Schweda [mailto:s...@antinode.info] 
Sent: Friday, September 30, 2011 11:13 AM
To: BUG-WGET@gnu.org
Cc: Metzler, Chris
Subject: Re: [Bug-wget] Recursive wget: change in handling of file
permissions?

 I need to be able to do recursive downloads while having the file
 permissions match my umask.  Is that no longer possible in more recent
 versions of wget?  Or am I doing something wrong here?

   I'm just a bystander here, but, so far as I can see, there's a
relatively unconditional chmod() in src/ftp.c, and has been since
around version 1.10.2.  (My Wget 1.10.2 on VMS tries to preserve the
original permissions, for example, just as the latest stuff does.)

   When Wget does a recursive FTP download, it fetches a directory
listing, and, if it can parse the thing, extracts the original
permission info from it.  Then, when it downloads a (plain) file, if it
has that file's permission info, then it'll do that chmod().  For a
non-recursive download (and without -N/--timestamping), there's no
need to get that directory listing, and without that listing, the
original permissions are unknown, so the chmod() is not done.

   Poking around through the scrap heap here, I can find traces of old
options like --preserve-permissions or --preservepermissions (and
variables like opt.preserve_perm), but all the 1.10.2-and-newer stuff
I've found does the chmod() whenever it has the necessary info (so, for
practically any recursive FTP download).  Unless someone modified your
1.10.2 program, or there's some exotic file-ownership/permissions quirk
involved, I can't explain why _your_ 1.10.2 program _fails_ to set the
original permissions just as the newer program does.

   If you can build the program from the sources, then it would be
pretty easy to find and disable that chmod() in src/ftp.c.  Adding a
command-line option to control that chmod() (as in the old days?)
doesn't appear as if it would be especially difficult, either. 
Persuading the Wget maintainer to make the change is a different kind of
task.



   Steven M. Schweda   sms@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547