[RFC] per-branch umask

[John Arbash Meinel]

Robey Pointer wrote:
> 
> 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!

Not really. Your StubSFTPServer says:
if attr:
  SFTPServer.set_file_attr(path, attr)

Which is really an os.chmod() call.

> 
> 
>> 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.

Basically, the chmod acts as a sync request, which would happen anyway
by the close. Sounds decent. I'll move where I'm doing the chmod.

> 
> (Hope that makes sense.)
>
> robey
>
>

Yes it does.

There is another issue, though. Pipelining doesn't work right away if
you are using SFTProcess (openssh instead of paramiko's connection).
Paramiko needs the function "recv_ready". Which for now I've just forced
with a "def recv_ready(self): return True)".
I assume that means it would block rather than being properly pipelined.

On win32, I don't think I have poll() or select(), so I'll just have to
do True. But I think for Linux I can do poll().

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051215/c610bfef/attachment.pgp