Doing #116 first, at least partially, should simplify debugging this.
[Issue created by Pidgeot: 2016-05-23]
[Last updated on bitbucket: 2016-08-08]
[Comment created by Pidgeot: 2016-08-08]
Removing milestone: 0.11a (automated comment)
[Comment created by Pidgeot: 2016-07-11]
Workaround sporadic shutil errors on Windows by retrying (fixes #117)
→ <>
[Comment created by Pidgeot: 2016-07-11]
While I don't think this particular solution is ideal by any means, it seems the least hacky way to deal with this.
This also seems to be the basic approach Mozilla uses in their mozfile module.
[Comment created by Pidgeot: 2016-07-11]
For reference, the alternative way this bug can manifest:
ERROR: Something went wrong while installing graphics
Traceback (most recent call last):
File "python_lnp\core\graphics.py", line 90, in install_graphics
if not update_graphics_raws(paths.get('df', 'raw'), pack):
File "python_lnp\core\graphics.py", line 272, in update_graphics_raws
if mods.update_raw_dir(raw_dir, gfx=(pack, built_graphics)):
File "python_lnp\core\mods.py", line 358, in update_raw_dir
shutil.copytree(paths.get('baselines', 'temp', 'raw'), path)
File "C:\Python27\lib\shutil.py", line 177, in copytree
os.makedirs(dst)
File "C:\Python27\lib\os.py", line 157, in makedirs
mkdir(name, mode)
WindowsError: [Error 183] Cannot create a file when that file already exists: u'.\\..\\gfx_test\\raw'
[Comment created by Pidgeot: 2016-07-11]
I think what happens here is that Windows sets off some sort of background task (folder thumbnail generation?) which of course traverses the folder.
When deleting the folder, it seems like this can then trigger a kind of race condition where the background task will temporarily hold on to some file handle and either prevent the folder from being deleted, or in some cases, prevent the directory from being re-created.
This can be worked around in various ways (call rmdir manually through os.system, rename the folder before deleting, etc.), but I'm not entirely happy with these approaches - I'd rather avoid calling a system command if possible, and renaming the folder potentially just pushes it further down the line. Will need to give this a bit more thought...
[Comment created by Pidgeot: 2016-07-10]
Seems that this is what's happening:
ERROR: Something went wrong while installing graphics
Traceback (most recent call last):
File "python_lnp\core\graphics.py", line 90, in install_graphics
if not update_graphics_raws(paths.get('df', 'raw'), pack):
File "python_lnp\core\graphics.py", line 272, in update_graphics_raws
if mods.update_raw_dir(raw_dir, gfx=(pack, built_graphics)):
File "python_lnp\core\mods.py", line 347, in update_raw_dir
shutil.rmtree(path)
File "C:\Python27\lib\shutil.py", line 256, in rmtree
onerror(os.rmdir, path, sys.exc_info())
File "C:\Python27\lib\shutil.py", line 254, in rmtree
os.rmdir(path)
WindowsError: [Error 145] The directory is not empty.: u'.\\..\\gfx_test\\raw'
From the forums:
http://www.bay12forums.com/smf/index.php?topic=126076.msg7006582#msg7006582 http://www.bay12forums.com/smf/index.php?topic=126076.msg7009423#msg7009423
Doing #116 first, at least partially, should simplify debugging this.
[Issue created by Pidgeot: 2016-05-23] [Last updated on bitbucket: 2016-08-08]
[Comment created by Pidgeot: 2016-08-08] Removing milestone: 0.11a (automated comment)
[Comment created by Pidgeot: 2016-07-11] Workaround sporadic shutil errors on Windows by retrying (fixes #117)
→ <>
[Comment created by Pidgeot: 2016-07-11] While I don't think this particular solution is ideal by any means, it seems the least hacky way to deal with this.
This also seems to be the basic approach Mozilla uses in their mozfile module.
[Comment created by Pidgeot: 2016-07-11] For reference, the alternative way this bug can manifest:
[Comment created by Pidgeot: 2016-07-11] I think what happens here is that Windows sets off some sort of background task (folder thumbnail generation?) which of course traverses the folder.
When deleting the folder, it seems like this can then trigger a kind of race condition where the background task will temporarily hold on to some file handle and either prevent the folder from being deleted, or in some cases, prevent the directory from being re-created.
This can be worked around in various ways (call rmdir manually through os.system, rename the folder before deleting, etc.), but I'm not entirely happy with these approaches - I'd rather avoid calling a system command if possible, and renaming the folder potentially just pushes it further down the line. Will need to give this a bit more thought...
[Comment created by Pidgeot: 2016-07-10] Seems that this is what's happening:
...why is it an issue? No idea at this point...