[merge][rfc] test that Transport.append sets permissions on existing files
mbp at sourcefrog.net
Fri Aug 17 03:57:58 BST 2007
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.
More information about the bazaar