[ 
https://issues.apache.org/jira/browse/BUILDR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628515#action_12628515
 ] 

Jared Robinson commented on BUILDR-143:
---------------------------------------

It appears from reading transports.rb, that for SFTP, it's possible to set a 
:permissions option -- although I don't know how to specify the option. So, it 
would be nice if for file:// uploads, setting the :permissions option worked 
similar to the way it works for SFTP permissions. Would that be something like 
one of the following?

1. upload artifact, :permissions => 0622
2. repositories.release_to[:permissions] = 0622

Having buildr honor my umask is good enough for now.

> Upload to a file:// path needs ability to specify permissions
> -------------------------------------------------------------
>
>                 Key: BUILDR-143
>                 URL: https://issues.apache.org/jira/browse/BUILDR-143
>             Project: Buildr
>          Issue Type: Bug
>          Components: Core features
>    Affects Versions: 1.2.10
>         Environment: Linux(RHEL 4) with a samba mount point
>            Reporter: Jared Robinson
>
> When uploading an artifact to a file:// repository URL, the permissions on 
> the artifact are rw by owner, but unreadable by anyone else. When I deploy to 
> a samba share, this is a problem, because no one else can read the artifact. 
> I've tracked it down to the use of Tempfile in transports.rb. Tempfile always 
> creates a file with permission 600. If I add the following code, everything 
> works as expected:
> temp.chmod(0644)
> I'd prefer it if the artifact was created using my default umask, and then 
> allow me to override it with an option :permissions so that I can specify 
> what file mode I want. So a better fix would be the following:
> temp.chmod(0666 - File.umask)
> This could be related to issue BUILDR-23

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to