Renaming a wiki page with attachments does not delete the old name attachment folder

[Francesca Mazzoni <francesca.mazzoni@…>]

I'm on Debian stable with Python 2.7.3 and installed from Debian package.

When I rename a Wiki page that contains attachments, the (empty) folder in which the attachments were stored before the page renaiming is still in the file system.

Steps to reproduce:

1) Create a new wiki page (say MyOldPage), add an attachment (say MyAttach.tgz). The attached file is stored in <trac-env>/attachments/wiki/MyOldPage/MyAttach.tgz.

2) Rename MyOldPage to MyNewPage.

The attachments are now (correctly) stored in <trac-env>/attachments/wiki/MyNewPage/.

I still have the <trac-env>/attachments/wiki/MyOldPage folder.

I think that the folder should be removed, since it is empty.

[Jun Omae]

Thanks for the report. Reproduced on 0.12-stable. The following patch would fix it.

trac/attachment.py

@@ -348 +348 @@
         def do_reparent(db):
             for attachment in list(cls.select(env, parent_realm, parent_id,
                                               db)):
-                attachment_dir = os.path.dirname(attachment.path)
+                attachment_dir[0] = os.path.dirname(attachment.path)
                 attachment.reparent(new_realm, new_id)
         if attachment_dir[0]:
             try:

I'll push the patch with unit test on 0.12.7.

[Jun Omae]

This issue occurs on only 0.12.x. Milestone 0.12.7 for only security fixes. But this issue is not a security issue. Should we fix it? or leave it?

[Ryan J Ollos]

My feeling is that it is really up to you, particularly since we've committed to at least one more release from the 0.12-stable branch. I'd probably go ahead and push the fix though if I had any use for 0.12.x.

After we do the 0.12.7 release though, if we are treating it as a security-fix only branch then future releases will only be as needed.

[Jun Omae]

Thanks for the comments. Fixed in [13610] and recorded only in [13611-13612].