[RFC] per-branch umask

[Robey Pointer]

On 15 Dec 2005, at 21:57, John Arbash Meinel wrote:

> Robey Pointer wrote:
>>
>> On 15 Dec 2005, at 15:36, John Arbash Meinel wrote:
>>
>>> 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).

Yeah, I saw that, looks interesting.  I have no way to test it, but I  
did save it.  Did you get the key list using the same protocol as in  
agent.py?  If so, I can probably hook them together pretty easily.   
(agent.py is surprisngly small.)

Putty SFTPProcess support would be orthogonal to pageant support,  
though.  In fact if you had putty process support, the pageant  
support would be moot.


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

Yeah, maybe a magic tuning variable is unavoidable.  If you want to  
play with a version of paramiko with this feature, I've posted a test  
branch here:

	http://www.lag.net/paramiko/bzr/paramiko-zapf

I set the limit at 10, hoping that was a good compromise value.

robey