On 22/03/14 22:29, Ignesias Tan wrote:
Hi Ignesias,Hey!Just wanted to say thanks for your bug-fix on launchpad for bug 788626, it worked like a charm thanks for contributing!!Quick question though, im a noob at programming and linux etc.. and i was wondering how you went about figuring the bug fix out?? I understand the concept behind the encrypted home folder and long filename problem, and i am familiar with how your fix works, but i was just curious about what you do/ how you go about figuring this stuff out.. i want to be able to debug stuff myself at some point and contribute also, but am clueless on where to start.. any help (even brief intro) would be greatly appreciated! thanks!-ignesias
first of all, it's nice to know that my temporary hack helped somebody else too. I had the issue myself, which is why I made the temporary solution. My motivation for writing answers like that is two-fold. If I don't write it down, I might get the same issue later and have to figure it out all over again - that's wasted time. If I write it down in a public forum, then I might save someone else's time as well. Just like I save time so often when I find that someone else already found a solution to the issues I'm having.
This one is so long ago, I barely remember how I went about figuring it out. My guess is I searched for the file name and found it more than one place. Knowing the issue was with encrypted homedirs, the obvious solution is to move the files away from it, but there was no configuration option for where to store this resume file, so moving the files would be pointless, as they would just be recreated in the same place. At this point, it helps to know a bit about how the Linux file systems (in this case, ext3) work. The symbolic link is a wonderful piece of functionality. When the program looks for the directory to store the resume file in, the file system tells it "yeah, here it is!", but behind the scenes, it actually redirects it to somewhere else. The program doesn't even know it, unless it specifically checks, which is pointless in most cases because it simply doesn't matter.
If you come from Windows, you'll be used to a pathetically featureless file system and probably do not know about symbolic links. I also came from Windows, but it's a decade since I switched, and you learn a bit in that long time. It probably took a couple of years before I used symbolic links myself, and even longer before I understood what to do with hard links. But just like important new knowledge in any field, doors open once you get the concept and start using it. I'd recommend reading about symbolic and hard links, then try to use them. Reading about something is good, but it's much more powerful if you actually use your new knowledge. And use the command line as much as possible in order to force yourself to learn more. I always copy files with cp, rsync or mcp and move (rename) with mv, rsync+rm, or mmv. You'll be able to do most user activity just fine without ever using the shell, but you won't be able to fix many issues, and thus contribute back to the community. And by learning how to manage your own computer from the shell (console), you'll also learn how to manage your own server(s), which can be on the other side of the earth, so you have no monitor access to them. ssh is the thing to use then. That gets you the shell of another computer. One more thing: man. This command is very valuable. Most command line programs have a manual entry. If you want to know about rsync for example, type "man rsync" into the console prompt. That's my first point of call. The second is Google or duckduckgo.com.
Don't worry about not being able to contribute directly yet. There are many ways to contribute, including simply reporting issues, giving debug information (log files, etc) to people who can help, and what you just did, saying thanks.
Ronny.
