inconsistent filename checking between 'add' and 'smart_add'
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Medium
|
Unassigned |
Bug Description
This doesn't seem quite right:
mwh@mithril-
mwh@mithril-
mwh@mithril-
mwh@mithril-
mwh@mithril-
mwh@mithril-
Python 2.4.4 (#2, Apr 12 2007, 21:03:11)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bzrlib.workingtree
>>> wt = bzrlib.
>>> wt.smart_
([u'a..b'], {})
>>> wt.add(['c..d'])
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/home/
return unbound(self, *args, **kwargs)
File "/home/
self.
File "/home/
return unbound(self, *args, **kwargs)
File "/home/
assert '..' not in f
AssertionError
>>>
I don't know what the correct behaviour _is_, but I think these two calls should probably succeed on the same filenames...
Changed in bzr: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Well, the check is actually meant to catch cases where someone is trying to do:
tree.add( 'foo/.. /bar')
You certainly should be able to add a file named "foo..bar".
So a better check might be "assert /../ not in f"
At least, by that point the path should be properly sanitized such that there are only forward slashes, and not backslashes. Otherwise a lot of the rest of the code would break anyway.-
I believe smart_add() is safe about it, because of how it recurses through the tree and normalizes the user's input. WT.add() is not safe about this, because it expects that the caller has already done it.
If you *really* need to work around it, notice that these are plain 'assert' cases, so running in python -O mode will skip the check.