Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I'm writing an installer script (run on a Linux box) that copies files from a source directory to a target directory. Then it attempts to set some permissions on the new files using chmod. When the code below is run, chmod always returns 1, but when I go look at the files, the permissions are set to 0664 instead of 0777! Any idea what's going on? Incidentally, the user I'm running the script as does have read/write/execute permissions to the installer's target and source directories.
foreach my $file(@toInstall){ print "Copying $file to $input{'installDir'}/..."; system("cp -Rf ./source/$file $input{'installDir'}/"); if(!(-e "$input{'installDir'}/$file")){ die "FAILED! Unable to complete file copy! DNE: $input{'insta +llDir'}/$file\n"; } print "done. Attempting to set permissions: "; print(chmod(0777,"$input{'installDir'}/$file")); print "\nFinished installing $file!\n"; }

Replies are listed 'Best First'.
Re: File Permissions
by bikeNomad (Priest) on Jul 22, 2001 at 22:52 UTC
    There is a per-process setting called umask that serves to reset permission bits. In your case, the umask is apparently 0113.

    Just use the perl umask built-in to change this for your process (only need to do it once):

    umask 0; chmod 0777, $file;

    However, do you really want rwx permissions for everyone?

    update: Randal's right; I assumed that umask worked on chmod too, but it doesn't.

      No, that can't be it. chmod is not affected by the umask. Only making a new file or new directory.

      I can't tell... is this a web script (if so, it's very dangerous) or a command-line script?

      -- Randal L. Schwartz, Perl hacker

        This is command line. 0777 is just for testing--the data it's copying at the moment needs 777, but eventually it'll be something more like 750 or 550.
      Aha! I found the problem. Later on in the script, some changes were made to the newly copied files--that is, a reader handle was opened on it, the unaffected parts were copied to a writer handle (opened on filename.ext.new), the new data was sent to the writer, and the remainder of the file copied over as well. Then the streams were closed, the original was unlinked, and the .new file was renamed in it's place. The umask was causing problems with the new file that was created by the writer, and setting umask(0) fixed it. Silly me. =) Thanks for the help guys!