Well, all the 'exceptions.AttributeError' stuff looks like just cleanup issues of the sftp system.
It would seem that the 'socket' module is somehow destroyed before the thread is told to cleanup, so then it tries to grab an attribute, but the module is already None.
It seems that for some reason, your sftp server threads are not shutting down when they are asked.
As for the mode 2666 problem. What do you recommend? We are testing that we can set mode = 02666 when requested. On NFS it seems that we can't. That would seem to be a genuine failure. It is a Platform Deficiency, and not a bug in bzr specifically. I'm not sure how to detect the specific deficiency, though.
If you can think of a way to detect that the platform won't do what we want, I suppose we could just skip the test.
(One possibility would be to create a different file, and directly chmod it to 2666, if that fails, just skip the test).
Well, all the 'exceptions. AttributeError' stuff looks like just cleanup issues of the sftp system.
It would seem that the 'socket' module is somehow destroyed before the thread is told to cleanup, so then it tries to grab an attribute, but the module is already None.
It seems that for some reason, your sftp server threads are not shutting down when they are asked.
As for the mode 2666 problem. What do you recommend? We are testing that we can set mode = 02666 when requested. On NFS it seems that we can't. That would seem to be a genuine failure. It is a Platform Deficiency, and not a bug in bzr specifically. I'm not sure how to detect the specific deficiency, though.
If you can think of a way to detect that the platform won't do what we want, I suppose we could just skip the test.
(One possibility would be to create a different file, and directly chmod it to 2666, if that fails, just skip the test).