[RFC] per-branch umask

[Robey Pointer]

On 15 Dec 2005, at 13:19, John Arbash Meinel wrote:

> Jan Hudec wrote:
>> On Thu, Dec 15, 2005 at 12:46:07 -0600, John Arbash Meinel wrote:
>>
>>> Matthieu Moy wrote:
>>>
>>>> Jan Hudec <bulb at ucw.cz> writes:
>>>>
>>>>
>>>>
>>>>> Ok or not, sftp does not support setting umask, so it's the  
>>>>> only way
>>>>> (short of requiring users to create wrapers for the sftp server).
>>>>
>>>>
>>>> If the performance loss is visible, then there should be a way to
>>>> disable the chmod.
>>>>
>>>
>>> Actually, I found a better way. The CMD_OPEN call for sftp lets you
>>> specify a file mode at creation time.
>>> Since sftp.put() always uses _sftp_open_exclusive() and puts the  
>>> file
>>> into a temporary file, we probably don't have to chmod the file  
>>> again.
>>
>>
>> So does open -- but masks it with umask. Isn't sftp the same case?
>
> Actually, the StubSFTPServer that we use does *not* mask anything when
> it does an open or mkdir. Which means that all the test cases pass,  
> but
> in actually testing it with a real sftp server, I found that the tests
> don't pass. Thanks for reminding me of this.

Weird, I would've thought umask would be handled automatically by the  
OS.  In fact the open(2) manpage says so explicitly.  Ghosts!


> So yes, there will be an extra chmod call. I found the part where
> mkdir() was doing it already. I don't know why I didn't look at  
> open at
> the same time.

There's (currently) no way to do an async chmod() call in paramiko,  
however you can do it in such a way that it's not noticeably slower.

When a file is pipelined, doing a close() on the file will cause  
remaining sftp server responses to be collected and scanned for  
errors, since this will be our last chance to report errors.  If you  
do the chmod right before closing the file, it will wait for the  
chmod response -- which will usually follow all of the "write"  
responses, and therefore soak up the same lag that close would've.

(Hope that makes sense.)

robey