Project not deleted from disk after delete_project called

[tmillross]

(Windows) To reproduce:

1. Open user projects directory, e.g: C:\Users[user]\AppData\Local\pylca\Brightway3
2. select or create a project (in AB) to test deletion, e.g. project name = "A1"
3. Check you can see the folder for that project in Explorer:, e.g. "a1.8a8bb7cd343aa2ad99b7d762030857a2"
4. Ensure project is selected as current and click 'Delete Current' button, then confirm with "Yes"
5. Project disappears from AB Projects list, but is still visible in Explorer
6. The folder also retains a lock, such that when you attempt to delete in Explorer, it says it's "in use"
7. Closing AB instance does not release this lock (so deletion still not possible, perhaps until logoff?)

An error message is not visible. Could be a permissions issue? Not sure if this happens on Mac / Linux. Or perhaps an issue in brightway2.projects.delete_project()

[haasad]

brightway has two ways to deal with this afaik:

• you can do: bw.projects.delete_project('my_proj', delete_dir=True)
• bw.projcets.purge_deleted_directories(), this will delete all folders of unused projects

I don't know what birghtway's reasoning is for keeping the data when a user deletes a project, but for the AB I'd be ok with just using the first option, ie. passing delete_dir=True. In general you're not supposed to change things in the brightway folder manually, but use utility functions like purge_deleted_directories.

[tmillross]

Ok great, thanks for coming back so quick on this @haasad! Tried the first one, with code:

       bw.projects.delete_project(bw.projects.current, delete_dir=True)

On attempting the deletion, hit the error:

Traceback (most recent call last): File "C:\code\activity-browser-upstream\activity_browser\app\controller.py", line 190, in delete_project bw.projects.delete_project(bw.projects.current, delete_dir=True) File "C:\Users[user]\Anaconda3\envs\ab\lib\site-packages\bw2data\project.py", line 300, in delete_project shutil.rmtree(dir_path) File "C:\Users[user]\Anaconda3\envs\ab\lib\shutil.py", line 494, in rmtree return _rmtree_unsafe(path, onerror) File "C:\Users[user]\Anaconda3\envs\ab\lib\shutil.py", line 384, in _rmtree_unsafe _rmtree_unsafe(fullname, onerror) File "C:\Users[user]\Anaconda3\envs\ab\lib\shutil.py", line 389, in _rmtree_unsafe onerror(os.unlink, fullname, sys.exc_info()) File "C:\Users[user]\Anaconda3\envs\ab\lib\shutil.py", line 387, in _rmtree_unsafe os.unlink(fullname) PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\Users\[user]\AppData\Local\pylca\Brightway3\a4.894f782a148b33af1e39a0efed952d69\lci\databases.db'

So I think best not to push that code change!

Tried the second one from console (whilst AB instance was still running):

bw.projects.purge_deleted_directories()

It successfully purged some of the project folders from disk.

Some of them were still retained, with the error received:

PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\Users\[user]\AppData\Local\pylca\Brightway3\a6.f74dd50cfec0f8549406fee6191d2f8d\lci\databases.db'

On closing AB, that file-lock was released, and running purge_deleted_directories() again deleted most of the remaining ones.

[haasad]

Seems to be a Windows issue with delete_dir=True: https://ci.appveyor.com/project/haasad/activity-browser/build/1.0.348#L981, tests on linux and mac ran fine.

We could do:

try:
    bw.projects.delete_project(bw.projecets.current, delete_dir=True)
except PermissionError:
    bw.projects.delete_project(bw.projecets.current)

However this still wouldn't delete the directory on windows. Do you think this is something we should fix? What made you investigate this in the first place?

[tmillross]

Your suggestion looks good - why not fix if it's as easy as that? :+1: I had lots of BW project data, taking up many GBs of my limited laptop space. And realised many of the (test) project folders were from ones I'd deleted previously, through AB. I was unaware that this was somewhat standard BW behaviour, probably not the only one though ;D