[          ]

Issue migrated (2015-06-05) from old issue tracker http://mirrorbrain.org/issues/issue20

Title    mb scan/probefile leaves temporary directories behind
 Priority   bug                Status         resolved
Superseder                    Nosy List       poeml
Assigned To poeml             Keywords

msg47 (view) Author: poeml Date: 2009-11-01.22:10:59

drwx------ 2 mirrorbrain mirrorbrain 48 2009-10-31 22:44 mb_probefile__30RC9
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 06:44 mb_probefile_QPfHmA
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 06:44 mb_probefile_-EUd23
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 06:44 mb_probefile_NDtT2m
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 06:44 mb_probefile_xFF50B
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 06:44 mb_probefile__-_NhU
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 06:44 mb_probefile_EhW8Mx
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 06:44 mb_probefile_CBTamD
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 20:44 mb_probefile_keI-Xv
drwx------ 2 mirrorbrain mirrorbrain 48 2009-11-01 20:44 mb_probefile_fjmV_C

These are empty directories, left behind by "mb scan" I think.

msg49 (view) Author: poeml Date: 2009-11-04.20:45:17

While the above was observed on a 64-bit openSUSE 11.0 install, I can't for some reason reproduce it on two other
systems: one with 32-bit openSUSE 11.0, one with 32-bit openSUSE 11.1.

The temporary directories are created by testmirror.py when it looks up files per rsync.

Given that I understand Python's except..finally statement correctly, the cleanup should always happen, because it is
under the finally clause:

  elif S.scheme == 'rsync':

      try:
          tmpdir = tempfile.mkdtemp(prefix='mb_probefile_')
          # [do stuff here]
      finally:
          shutil.rmtree(tmpdir, ignore_errors=True)

      return

Thus, it shouls always be executed. There is no reason for errors (shutil.rmtree is recursive, and there is no
problem with file ownership to be expected).

All the machines I tested on have Python 2.5, and as far as I know, the finally clause for except..finally was (re-
)added with Python 2.5.

However, SLE10, where MirrorBrain is deployed extensively as well, there is Python 2.4. So I'm actually not sure why
the code works there at all. A small test program shows that 2.4.2 indeed has support for except..finally:

!/usr/bin/python

import sys

try:
print 'in the try clause'
sys.exit(0)

finally:
print 'in the finally clause'

/tmp/t.py

in the try clause
in the finally clause

Replacing the sys.exit(0) with raising an exception, or just removing it, all works correctly.

The only thing that I can imagine is that the backported "processing" module on SLE10 influences the exception
handling in some unfortunate way. But that's only a very wild guess.

msg66 (view) Author: poeml Date: 2009-11-30.01:00:46

As the problem doesn't occur in most setups, and I can't reproduce it anymore (no
access to the previous machines anymore), I see no immediate need to pursue it.

msg100 (view) Author: poeml Date: 2009-12-07.03:18:38

Okay, I'll just close this now.

History
         Date         User  Action             Args
2009-12-07 03:18:38 poeml set    status: deferred -> resolved
                                   messages: + msg100
2009-11-30 01:00:47 poeml set    status: chatting -> deferred
                                   messages: + msg66
2009-11-04 20:45:18 poeml set    status: unread -> chatting
                                   messages: + msg49
2009-11-01 22:10:59 poeml create

(end of migrated issue)