Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Delete action for non-existent files and must_exist=1 #906

Closed
bdbaddog opened this issue Jan 2, 2018 · 0 comments
Closed

Fix Delete action for non-existent files and must_exist=1 #906

bdbaddog opened this issue Jan 2, 2018 · 0 comments

Comments

@bdbaddog
Copy link
Contributor

bdbaddog commented Jan 2, 2018

This issue was originally created at: 2004-09-06 13:08:42.
This issue was reported by: kquick.
kquick said at 2004-09-06 13:08:42

Fixed delete to properly generate an error if must_exist=1 and the file
does not exist. Previous version would attempt a shutil.rmtree if the
entry was not an os.path.isfile(), and shutil.rmtree doesn't complain
about a non-existent entry.

stevenknight said at 2004-09-13 13:51:04

Kevin--

What version of Python are you using, on what operating system?

The test/Delete.py script already has a test at the end for
a non-existent file, and on both my Red Hat 9 system and my
Windows 2000 system, shutil.rmtree generates an error in
this case.

Actually, it would probably be friendlier, as well as more
consistent, to raise an explicit error instead of just
letting the underlying Python library generate a stack trace...

   --SK

kquick said at 2004-09-13 21:27:25

This patch was based on failures of test/Delete.py from a CVS snapshot of 6
Sep; there don't appear to have been relevant changes since then, but it may
not exactly match 0.96.1 in this regard.

The shutil.rmtree is being invoked with a second argument of 1, which is the
ignore_errors argument, therefore no error is getting signalled on a non-
existent directory. I didn't actually change that argument because I assumed
that the setting was purposeful to address issues like permissions errors in the
tree or something similar that wasn't considered fatal.

If you invoke shutil.rmtree with a second argument of False or equivalent (or
unspecified which defaults to false) then an appropriate exception gets
generated.

I opted to allow os.unlink to generate the exception since I knew it would do
so in the appropriate manner; throwing the exception manually would require
emulating the activity... I took the easy way out. It is a bit uglier though...

[Not to avoid your question:
$ python
Python 2.3.3 (#1, May 27 2004, 20:44:16)
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import os,shutil
a='no_file'
os.path.exists(a)
False
os.unlink(a)
Traceback (most recent call last):
File "", line 1, in ?
OSError: [Errno 2] No such file or directory: 'no_file'
shutil.rmtree(a)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/shutil.py", line 140, in rmtree
raise exc[0], (exc[1][0], exc[1][1] + ' removing '+arg)
OSError: [Errno 2] No such file or directory removing no_file
shutil.rmtree(a,1)

stevenknight said at 2004-09-14 16:42:00

Aha! You're seeing this problem because of a difference in
the Python 2.3 version of shutil.py. In both Python 1.5 and
2.2 (the versions I test against), the "ignore_error"
try:-except: block in shutil.rmtree() is inside the loop
that executes the function for each entry in the tree.

There's an initial helper function call, however, that
actually walks the tree and makes a list of all the entries.
In 1.5 and 2.2, this helper function call is outside of
the try:-except: block, so on those versions the exception
generated when the specified path name doesn't exist
percolates up to the SCons code that's expecting it. In
2.3, they fixed this by putting the try:-except: block
around the helper function call as well as the
execute-the-function loop.

So this explains why I'm not seeing the same problem you
are. I'll go ahead and continue with the integration. Thanks!

   --SK

stevenknight said at 2004-09-14 18:38:08

Integrated for next release. Thank you! --SK

issues@scons said at 2004-09-14 18:38:08

Converted from SourceForge tracker item 1023276

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant