I was able to get the desired behavior by adding the following to line 1438
in s3cmd (version 1.0.0):
os.chmod(filename, 0644)
Probably not an ideal patch for everyone but it works for my purposes. It
would probably be good to fix the gpg_decrypt function so that the
permissions behave in
On Mon, Mar 14, 2011 at 04:25, Daniel Stevens wrote:
> It may also be important to note that I'm using gpg encryption/decryption on
> the files.
Bingo. I just tested this and experienced the same. The reason is
due to the decryption occurring in /tmp. The encrypted file is
fetched from S3,
It may also be important to note that I'm using gpg encryption/decryption on
the files. Perhaps something in the decryption process is setting the strange
permissions? Any way to get it to set standard permissions?
On Mar 14, 2011, at 2:17 AM, Jim Popovitch wrote:
> On Mon, Mar 14, 2011 at 03:
Hi Jim,
My umask is 0022. Anytime I create a file (like via: touch file) the
permissions are set to 644 but for some reason all files pulled via 's3cmd get'
are all set as 700. Help would be greatly appreciated.
Thanks,
Dan
On Mar 14, 2011, at 2:17 AM, Jim Popovitch wrote:
> On Mon, Mar 14,
On Mon, Mar 14, 2011 at 03:12, Daniel Stevens wrote:
> Hi list,
>
> Anytime I run s3cmd get on a file it creates the file with a chmod of 700
> (-rwx--) which is rather odd. How can I get the file to automatically
> chmod to the standard 644 (-rw-r--r--)? I've tried --preserve and
> --no-prese
Hi list,
Anytime I run s3cmd get on a file it creates the file with a chmod of 700
(-rwx--) which is rather odd. How can I get the file to automatically
chmod to the standard 644 (-rw-r--r--)? I've tried --preserve and
--no-preserve among many other things and it gets tiresome following each
g
