[merge][rfc] test that Transport.append sets permissions on existing files

[Martin Pool]

On 8/17/07, John Arbash Meinel <john at arbash-meinel.com> wrote:

> In the current code, we never pass a mode flag to append. Because we
> assume that you did the right thing when creating the file.
> It means that if you update the .bzr we won't update files underneath
> it, but I think that is okay.
>
> I would be fine with deprecating the mode bits on Transport.append() and
> just expect them to be accepted for put_non_atomic() et al.

You can use append to create a new file.  In that case it is sensible
and indeed necessary that it should take a mode flag, and we should
test this.  It might be that we never do this from current formats but
I think we did in the past.

It might be reasonable to say that Transport callers should always
know whether the file they're creating will exist or not, and call
put_* or append respectively.  This would let us have some checks
against things like the paramiko misbehaviour reported a while ago.

My question was really about the more common use of append to write to
an existing file.  Does it need to reset the permissions then?  I
wouldn't think so, since that would imply they were wrong before.
Unless someone knows a reason why it's in there, I'd rather remove the
code that does it.

-- 
Martin