@ Luke Maciak:
It was my local system. That old ThinkPad T20. And busybox and toybox aren’t just for system rescue and embedded systems. I used to use just busybox as my coreutls package, now I use combination of toybox and busybox.

I have messed up badly couple of times with the rm command…

My own site is build using Jekyll also, but I always run it from the directory where my site is in, so I don’t accidentally make the same mistake :D If possible I always run all commands on the same directory I am in if there is even small change of destroying files.

Mostly because I am lazy and its easier to stay in the directory where the project/files are.

@ JuEeHa:

Whoops. Gotta love Unix for even letting you do something like that. Was this a remote system? If it was local, I would just power it down and boot it of any available live CD and restore /bin that way.

Oh, and thanks for mentioning busybox/toybox. TIL :) It seems like these apps can be lifesavers.

Hello from consoleland! I was once installing some software from source. (I don’t remember what software but it was quite old unix utility.) I had used su -c ‘make install’ and for some reson it didn’t have default prefix set as / or /usr but rather current working directory. Well I didn’t want it there so I just ran “rm -rf ./bin”. Well actually I forgot the “.” and resuts weren’t pretty. Luckily once I had suffered my first hard drive crash and lost almost all of my data I have taken my backuping seriously and I had complete copy of my system. It was actually kinda interesting to restore system using only stuff in /usr/bin (no coreutils on busybox system) and staticaly built toybox (like busybox but with less utilities and better (more permissive) license). It wasn’t that bad but I kinda missed cp.

@ Chris Wellons:

Ok, there was an existing site living at the root directory. Before my little “accident” if you went to /~maciakl there was stuff there. So when I created the blog, I put it in /~maciakl/blog.

And yes, when I’m writing new entries I just run jekyll –server locally – hence the auto in the config. The issue was when deploying the site to the server.

The WebDav directory has some weird file-locking issue going on. Initially I had a simple rsync script that would sync _site to the remote directory. But somehow the server would panic when that happen and issue some sort of temporary write-lock. So every time I would end up with a half-uploaded site, and had to wait about an hour or two and manually copy over missing files.

Eventually I discovered that if I just do jekyll –no-auto /remote/dir/blog this did not happen. Somehow the locks would not get triggered and Jekyll would just build my site in the production folder and all would be well.

Until the time I mistyped the command and it clobbered the directory.

The stuff that was there was the old website – one I wasn’t working on at the moment so I did not have it in any open buffers. :P

I noticed this new blog when you started the repository for it on GitHub. As one of your followers I get a message every time you start a new repository. :-)

I don’t understand, how did you clobber files in the parent directory? Didn’t Jekyll just create a _site directory with a copy of all your files?

I notice you’re specifically using --no-auto while your config has auto turned on. Why do you do it this way? When I’m working on a post, I use auto specifically so I don’t have to go run a command every time I want to check my work. (I actually run Jekyll as an inferior process to Emacs, so no terminal is involved at all.) Jekyll will update the website every time I save so all I need to do is refresh the browser. My current problem is that my blog is large enough that it takes Jekyll a couple minutes to generate. I think I mentioned this before.

Finally, since I never exit Emacs, if somehow my work gets clobbered on the file system I still have a volatile backup of my work in the form of Emacs’ buffers. This has saved me 10-15 minutes of effort a couple times when my work was accidentally clobbered (typo in a Makefile, etc.) before I committed it to Git.