fuse errors when using tmsu with zsh
Philipp Specht
I tried running the both the binary build (0.0.8 from
https://bitbucket.org/oniony/tmsu/downloads/tmsu-x86-0.0.8.tgz) as well
as a version compiled from source against Go . Both versions worked
fine, when it came to tagging files, but using the mounted VFS was
impossible using zsh: cd'ing or ls'ing the tags directory returns the
following (or similar, but the tag 'debian' definitely exists and is
accessible using other means, see below) errors.
> ls: cannot open directory .: Transport endpoint is not connected
> cd:cd:6: transport endpoint is not connected: tmsu/tags/debian
Using bash or a graphical file manager (thunar, in this case) all this
works fine. Using root (or sudo) results in the same problems, using
bash, everything works, using zsh breaks cd'ing into the directories.
I cannot think of any explanation but some incompatibility with zsh's
built-in cd, which, of course, seems unlikely -- even more so since you
seem to use zsh as well -- but I really am out of other ideas as to what
might cause this strange behavior.
I've attached some version information below, if you need additional
info or want me to try something, don't hesitate to let me know.
Thanks for taking the time to read all this,
Phil
______
Ubuntu 12.04
Kernel 3.2.0-26-generic #41-Ubuntu SMP x86_64
fuse-utils 2.8.6-2ubuntu2
zsh 4.3.17
Paul Ruane
That is indeed a very strange problem. I'll have a look tomorrow to see if I can reproduce this bug — it's certainly not something I have seen or had reported before.
Would you mind testing with a default .zshrc or sending me your .zshrc in case it is related to a Ash setting you have turned on that I don't?
Many thanks,
Paul
Paul Ruane
Thank you for investigating this further. I'll have a look through your config though I can't think what it could be.
The transport not connected error I get if the process hosting the VFS errors. What I tend to do is run this process manually instead of using 'tmsu mount'. If you wouldn't mind trying this I would be very interested in the error shown. The syntax is as follows:
>tmsu vfs path/to/db path/to/mount point
The process runs foreground and should write a stack trace when it dies, assuming that it is dying.
Paul
Tried reproducing the error with an empty .zshrc, everything works just fine. So the problem probably is due to some weird config setting. My zsh config is on github, see https://github.com/dadrc/zsh-cfg
The two functions involved above look as follows, in case there is something obviously wrong about them.
ls: aliased to ls -b -CF --color=auto
cd () {
if (( ${#argv} == 1 )) && [[ -f ${1} ]]
then
[[ ! -e ${1:h} ]] && return 1
print "Correcting ${1} to ${1:h}"
builtin cd ${1:h}
else
builtin cd "$@"
fi
}
I will try to track down the offending setting and report here if I'm successful.
Thanks for the hint,
Phil
PS: I didn't get your answer mail from the mailing list although I subscribed, so this answer comes to you straight from Google Groups, I hope this doesn't screw up your thread view.
On Saturday, 21 July 2012 23:19:58 UTC+2, Paul Ruane wrote:
That is indeed a very strange problem. I'll have a look tomorrow to see if I can reproduce this bug — it's certainly not something I have seen or had reported before.
Would you mind testing with a default .zshrc or sending me your .zshrc in case it is related to a Ash setting you have turned on that I don't?
Many thanks,
Paul
Philipp Specht
/tags, it failed with
~/tmsu/tags:$ ls
tmsu: Could not lookup tag IDs: No such tag '.git'..
and quit. Not quite sure where it got the '.git' tag from, I did not
define it and it's not contained in the sqlite file.
sqlite> select * from tag;
1|iso
2|debian
3|ubuntu
4|rescue
5|desinfect
Still doing some maintenance on my zshrc, no luck so far, even though
I got rid of some old grml settings.
Phil
2012/7/21 Paul Ruane <oni...@gmail.com>:
Paul Ruane
It seems then that something in your .zshrc is checking whether there is a '.git' directory each time you run 'ls' (for whatever reason). This perfectly reasonable behaviour, though for your own peace of mind you may want to track it down.
Because the TMSU VFS is only expecting operations on valid tags, this is causing the error. Ultimately it's the fault of TMSU (and therefore me) as what it should be doing is reporting that the directory does not exist rather than dying.
I'll push out a fix for this in the next few days. Apologies for the hassle it has caused you and thanks for helping me track it down.
Paul
Philipp Specht
and displaying some information about it if that's the case. The
function itself is documented at
http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Version-Control-Information
– it's part of zshcontrib.
Thanks for tmsu and your help figuring this out,
Phil
2012/7/22 Paul Ruane <oni...@gmail.com>: