In my super-massive vim post I have mentioned that CTAGS are the bees-knees of vim lifestyle. A lifestyle which may not be as glamorous as that of marketrioid marsupials for example, but we fucking like it. I just found a wee bit issue while tagging code, so I decided to document it here.
You see, one of my original purposes for writing this here online diary of sorts was chronicling my miss-adventures in technology. Back then I was in school, learning to program, and discovering Linux. Whenever I learned something interesting, or solved some issue I always had that feeling of “I should probably write this down somewhere, because it is bound to come up again”. Naturally I never did, and kept slamming face first in to same exact problem every 6 months or so (ie. every time Ubuntu decided to fuck me over releasing a shiny new update that of course would break everything on my laptop). Eventually I realized that I could use my blog (which then I used mostly for “I am angry at this news article I found on /.” posts) as a virtual sysadmin notebook. So I would write down my problem, my solution, and promptly forget about it. Six months later I would have a temporary bout of amnesia and do apt-upgrade-and-break-everything again, because compiz got like a new shiny bauble or something. This would invariably make my laptop stop working in all possible ways, and I would spend many unhappy hours googling stuff barfed up by dmesg. And I would find my blog, with the solution.
Since then Terminally Incoherent has evolved into something entirely different. But I still need a place to chronicle weird technology things. I could start a new blog for that, but… You know… Lazy. So I will leave this here if you don’t mind.
The other day I was happily running ctags -R on some php code and suddenly it vomited a whole slew of errors like this at me:
ctags: Warning: cannot open source file “index.php” : Value too large for defined data type
Apparently every single file in that directory was “too large for defined data type”. Of course the first thing I did was to google that message, but that didn’t actually do me much good. Turns out that this message has nothing to do with exuberant-ctags, and has everything to do with networking. In fact it is precisely a CIFS issue.
Here is a little background – the code I was trying to tag was hosted on a windows machine. I was sitting on Ubuntu box (yes, right on top of it) and accessing it remotely. Why? Well, I figured I might as well keep the code in the environment that closely resembles how it will be deployed (ie WIMP setup). At the same time I wanted to be comfortable, coding on my primary work rig which just happens to run Ubuntu. So I hooked the test win-box to the local network, created a network share for the code directory and mounted it on my machine using the following fstab entry:
//server/share /remote/s/ cifs rw,user,noauto,username=foo,password=bar,domain=baz,uid=1000,gid=1000 0 0
It turns out that there is some weird buffer overflow condition in CIFS that only occurs in some contexts, and only when dealing with a remote Windows share. 90% of other applications either don’t notice it, or just don’t give a shit. Exuberant Ctags however throws a fit and refuses to read files on a CIFS drive. Fortunately, there is an easy workaround. You simply have to add following options to your fstab entry: nounix,noserverino.
So the above line should look like this:
//server/share /remote/s/ cifs rw,user,noauto,nounix,noserverino,username=foo,password=bar,domain=baz,uid=1000,gid=1000 0 0
Hopefully this will help some other poor soul who made the folly of using ctags on a cifs share. It will probably help me at some point down the road, when I manage to forget all about this.