[win32] Permission denied in fancy_rename

[John Arbash Meinel]

Robert Collins wrote:

...

> 
> In assessing an interface, it helps to look at failure modes,
> particularly ones that wont be obvious. Having 'this file will be open
> because you neglected to read it' is such a failure mode.

Well, supposedly files don't close themselves properly either. (At least
we operate under that assumption).

But yes, I agree that dangling generators are unpleasant. I also wonder
what happens when they just disappear off the stack. Do they just get
garbage collected? And if so, is there some way to tie into that to make
sure things get cleaned up.
If it is just regular garbage collection, it seems like we would close
the file handles at least as well as we are closing them now.


> 
>> Besides, we are still supporting the get() interface, if you want to be
>> able to close early. It is just for when we are copying all of the file
>> between two locations like with:
>>   t1.put('foo', t2.get('foo'))
>>
>> That we want to switch to get_bytes/put_bytes.
> 
> Erm, surely t2.copy_to(['foo'], t1) is nicer than put(get) anyway?
> (because it allows fast-path optimisations which the less expressive
> 'I'm doing a put and a get' doesn't.
> 
> Rob
> 

I agree that is nicer. However, the line in question is line 363 of
knit.py which interestingly enough is annotated as a "robertc" line:
transport.put(name + INDEX_SUFFIX + '.tmp',
self.transport.get(self._index._filename),)

Now, I'm not harassing you too much, since the reason you had to do
that, was you were putting it into another file with a different name.

At one point I had put a comment that 'copy_to' really should take a
source and destination path. It is actually part of the
Transport.copy_to interface documentation string.

Unfortunately, the only way to do it compatibly is to either use a magic
function, or to create a new function.
(If relpaths is a list of tuples, you could assume from & to).

Now, the default implementation of copy_to is just put(path, get(path)),
but it would only require fixing it in one spot.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060503/12aeafad/attachment.pgp