"bzr branches" crashes on recursive symbolic link (from Wine)

Bug #279583 reported by DanielBachran
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned

Bug Description

Hello, upon starting to write a comment for https://bugs.launchpad.net/bzrtools/+bug/240891, I've noticed that the "bzr branches" command not only takes a long time to list all branches, but actually crashes with "Transport error: [Errno 40] Too many levels of symbolic links".

I'm running bzr 1.7.1 on Linux and I have the following plugins installed:
- bzrtools 1.7.0
- difftools
- gtk 0.95.0
- launchpad

Detailed error message:
-------- snip --------
bzr: ERROR: Transport error: [Errno 40] Too many levels of symbolic links: u'/home/g0ph3r/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.googleearth/instance-running-lock/.bzr/branch-format' [Errno 40] Too many levels of symbolic links: u'/home/g0ph3r/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.googleearth/instance-running-lock/.bzr/branch-format'
-------- snip --------

I have Wine and Google Earth installed. Although Google Earth was not running, so the "instance-running-lock" symbolic link seems to be old:

-------- snip --------
$ ll .googleearth/instance-running-lock
lrwxrwxrwx 1 [...] .googleearth/instance-running-lock -> /proc/11613

$ ll /proc/11613
ls: cannot access /proc/11613: No such file or directory

$ ll .wine/dosdevices/c\:/windows/profiles/g0ph3r/My\ Documents
lrwxrwxrwx 1 [...] .wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents -> /home/g0ph3r/
-------- snip --------

While running "bzr branches" again I verified that no process exists with the id 11613.

I've tested manually cd'ing into those recursive softlinks, to check how bash or my kernel behave. Interestingly, I do not get any further than this, which is similar to where "bzr branches" failed as well:

-------- snip --------
[~]$ cd '/home/g0ph3r/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/'
bash: cd: /home/g0ph3r/.wine/dosdevices/c:/windows/profiles/g0ph3r/My Documents/ [...] My Documents/.wine/dosdevices/c:/windows/profiles/g0ph3r/: Too many levels of symbolic links
-------- snip --------

I've counted 41 softlinks in this command ("c:" and "My Documents"), which means that both bash and "bzr branches" didn't like the 42th softlink...

I've reported this bug merely to report the crash, although it may well be that this does not affect bzrtools but rather bzr itself... So please feel free to "move" this bug over to bzr, if needed (and if this is possible?).

Slightly unrelated:
In order to work around the slow performance of "bzr branches" I wrote a quick bash function (using find, see below) to suit my needs. Yes, I have a lot of subdirectories within my home dir, but anyways, if find can traverse them that quickly, why not "bzr branches"?

Here's a real life example of what I mean with "slow performance":

Running the find command from my home dir took 10s.

Running "bzr branches" took 800s, using 100% CPU (well, one core ;-) during the whole time until it crashed. Memory usage was not so bad (started around 10MB or so, and went up to above 40MB, from what I can tell).

Additional information:
- find command: find . -type d -name .bzr -prune -printf "%h\n"
- Number of subdirectories within my home dir: 3052 (output of "find . -type d -name .bzr -prune -or -type d | wc -l")

Revision history for this message
Aaron Bentley (abentley) wrote :

The bzrtools "branches" command uses a bzrlib API to iterate through branches. This means that it works on any URL type bzr supports, and it supports repository types whose branches are not physically represented as directories. It is slow because bzrlib has not been optimized for this.

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

I can reproduce this as well. I often use symlinks pointing at the directory of the symlink.

Changed in bzr:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
James Westby (james-w) wrote :

This makes it impossible to run "bzr check" in a project which has
recursive symbolic links anywhere underneath it, even if they are
not part of a branch.

I have a project like so:

   shared-repo
      branch
      normal-dir
         subdir
           link -> ..

and the link in a dir that isn't really anything to do with the branch
breaks "bzr check", in this case making it very hard to upgrade to
2a.

Thanks,

James

Martin Pool (mbp)
Changed in bzr:
status: Triaged → Confirmed
Jelmer Vernooij (jelmer)
tags: added: find-branches symlink
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.