inconsistent filename checking between 'add' and 'smart_add'

Bug #132639 reported by Michael Hudson-Doyle
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

This doesn't seem quite right:

mwh@mithril-inside:tmp$ mkdir blah
mwh@mithril-inside:tmp$ cd blah
mwh@mithril-inside:blah$ bzr init
mwh@mithril-inside:blah$ touch a..b
mwh@mithril-inside:blah$ touch c..d
mwh@mithril-inside:blah$ PYTHONPATH=~/src/bzr/ python2.4
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 ='.')
>>> wt.smart_add(['a..b'])
([u'a..b'], {})
>>> wt.add(['c..d'])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/mwh/src/bzr/", line 50, in tree_write_locked
    return unbound(self, *args, **kwargs)
  File "/home/mwh/src/bzr/", line 126, in add
    self._add(files, ids, kinds)
  File "/home/mwh/src/bzr/", line 50, in tree_write_locked
    return unbound(self, *args, **kwargs)
  File "/home/mwh/src/bzr/", line 162, in _add
    assert '..' not in f

I don't know what the correct behaviour _is_, but I think these two calls should probably succeed on the same filenames...

Revision history for this message
John A Meinel (jameinel) wrote :

Well, the check is actually meant to catch cases where someone is trying to do:


You certainly should be able to add a file named "".

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.

Aaron Bentley (abentley)
Changed in bzr:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Achim Bohnet (allee) wrote :

This bug was marked as dup. of #145207 a showfoto crash. That's wrong.
Please use the correct bug number.

Revision history for this message
Martin Pool (mbp) wrote :

This assertion is no longer present

Changed in bzr:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers