bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Metzler, Chris
Subject: Re: [Bug-wget] Recursive wget: change in handling of file permissions?
Date: Mon, 3 Oct 2011 09:40:37 -0400

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
address@hidden
-----Original Message-----
From: Steven M. Schweda [mailto:address@hidden 
Sent: Friday, September 30, 2011 11:13 AM
To: address@hidden
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               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547



reply via email to

[Prev in Thread] Current Thread [Next in Thread]