[RFC] per-branch umask

[John Arbash Meinel]

Robey Pointer wrote:
> 
> On 15 Dec 2005, at 15:36, John Arbash Meinel wrote:
> 
>> Robey Pointer wrote:
>>
>>>
>>> On 15 Dec 2005, at 13:19, John Arbash Meinel wrote:
>>>
>>>> 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.
> 
> 
> Doh.  Right.  It's abstracted away too much because 'attr' can also 
> hold utime and chown data.  Never mind. :)  We could fix  StubSFTPServer
> if this matters (patch attached).
> 

I would like StubSFTPServer to be as much of a real server as we can.
This also means fixing the chmod after os.mkdir()

I went ahead and applied your patch in my permissions branch, and I'll
put in another one for the mkdir() call.

> 
>> 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().
> 
> 
> Oooh, good catch!  I wonder if this has been slowing down sftp  pushes. 
> Almost certainly, but how much...
> 
> Windows currently has no way to use SFTPProcess, because only unix-
> based ssh clients are supported, so Windows is always using  paramiko. 
> Thus (for now) just doing a select() should work fine.

Eventually, I would like to see putty() or maybe even cygwin ssh supported.

I don't know if you followed my posting, but I did write up a python
script which by using win32all and ctypes is able to talk to pageant. I
wasn't sure about how to integrate it into paramiko, but I was thinking
to look into it. I was able to request the list of agent keys, so I'm
pretty sure it is working.

Pageant seems to uses Windows event messages to pass the name of a named
memory page to read and write from. And then the communication messages
are just standard ssh-agent statements (at least as much as I can tell).
I would like to see a little bit more privacy in the memory page names
(they are unique by using GetThreadId, but I don't think that makes them
hidden enough as also having a random number).

> 
> [[[ idle thoughts follow:
> Paramiko is assuming it has a socket-like object, not a file.  You 
> might try having recv_ready() always return False, which would force 
> all async responses to buffer up until the file is closed.  However,  I
> think I've seen some sftp servers disconnect in this case -- they  keep
> getting requests but they can't write responses because the  responses
> have filled up the OS buffers and TCP windows.  Paramiko  could also be
> a bit smarter and track unack'd async requests, forcing  a read after
> some threshold is reached, but that turns into a  magickal tuning value.
> ]]]
>
> robey
>
>

I would say that you could use some sort of buffer. So you would give
yourself X un-acked requests. I think even a low number like 2 or 3
would help a little bit with pipelining as you can have 1 being copied
while the next one is being requested, and another one is being
acknowledged, etc.

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/466729c5/attachment.pgp