Archive for April, 2010

SourceForge Country Blocking Download Forbidden  We cannot send this file to your location. Please visit our our T7 page Source-Forge, The huge open-source software repository recently has banned some countries from downloading free and open-source softwares from their servers. However there’s a quick trick which you can download the files directly from source-forge mirrors, bypassing that IP address check.

Source Forge Download PageYou can click on the file you wanna download inside the “Files” section and take care when the following page appeared press ESC key to stop loading the page.

Source Forge Download LinkNow right-click on “direct link” and Copy the link address and Paste it into your address bar. It should look like this :

http://downloads.sourceforge.net/project/openproj/OpenProj%20Binaries/1.4/openproj_1.4-2.deb?use_mirror=surfnet

The last part, marked as red, shows the mirror you’re going to download from. Turn the URL into something like this :

http://surfnet.dl.sourceforge.net/project/openproj/OpenProj%20Binaries/1.4/openproj_1.4-2.deb

And it will download the file directly. In addition, some mirrors are not accessible because of routing path problems. I usually use “kent” as my mirror.

I just pressed the Enter key on the file delete confirmation dialog, and removed my code which I was working on for 3 hours. In fact I had made such a mistake before and had no results searching “Ext3 Recovery / Ext4 Recovery …”. But this time, a new project named extundelete appeared which claims to extract file metadata from the file-system’s Journal.

I tried to extract and compile it by just typing “make” and found that ext2fs library is missing, so I installed ext2fs-dev package using the following command (I’m using Ubuntu 9.10) :

sudo apt-get install ext2fs-dev

Then typing “make” in the src folder, presents you the binary file named “extundelete”. You can run it like this :

ali@Velocity:~/tmp/extundelete-0.1.8/src$ ./extundelete
No action specified; implying --superblock.

Usage: ./extundelete [options] [--] device-file

Options:
--version, -[vV]       Print version and exit successfully.
--help,                Print this help and exit successfully.
--superblock           Print contents of superblock in addition to the rest.
                       If no action is specified then this option is implied.
--journal              Show content of journal.
--after dtime          Only process entries deleted on or after 'dtime'.
--before dtime         Only process entries deleted before 'dtime'.

Actions:
--inode ino            Show info on inode 'ino'.
--block blk            Show info on block 'blk'.

--restore-inode ino     Restore the file(s) with known inode number 'ino'.
                        The restored files are created in ./RESTORED_FILES
                        with their inode number as extension (ie, inode.12345).

--restore-file 'path'  Will restore file 'path'. 'path' is relative to root of
                      the partition and does not start with a '/'
                      (it must be one of the paths returned by --dump-names).
                      The restored file is created in the current directory
                      as 'RECOVERED_FILES/path'.

--restore-files 'path'    Will restore files which are listed in the file 'path'.
                    Each filename should be in the same format as
                    an option to --restore-file, and there should be one per line.

--restore-all          Attempts to restore everything.
-j journal             Reads an external journal from the named file.
-b blocknumber         Uses the backup superblock at blocknumber when
                                opening the file system.
-B blocksize           Uses blocksize as the block size when opening fs.
                       The number should be the number of bytes.

It seems that running the program with –restore-all, should restore all possible files. Like this :

ali@Velocity$ ./extundelete /dev/sda6 --restore-all

But that option gave me some temporary, hidden and some useless config files over my home folder. I was thinking of rewriting the code …

Suddenly I found that, extundelete supports another option in which you can specify the inode number of your file, and it will bring it back … 🙂

Looking at manual of the “ls” command you’ll find that running “ls” with -i parameter will give you the inode number of files in a directory. I tried to find a range for inode files around the deleted file and search for all files in the range …

ali@Velocity:~/projects/Monko-MovieQuiz/Source/IMDBot/src$ ls -i
7824227 artists.db
7824222 google_spell_checker.py
7824220 merge_tool.py
7824214 movies-merged.db
7824219 movies-vahid.db
7824260 stuff.py
7824252 artists.py
7824211 IMDB.py
7824221 MovieDatabase.py
7824254 movies-sohrab.db
7824256 question_validator.py
7864492 tests
7864514 cache
7824305 lite_tool.py
7824208 MovieDatabase.pyc
7824207 movies-soroush.db
7824293 start.py
7962711 Tools

It seems that most of the files are in the range of 7824xxx, so searching the range of to 7824000 to 7824999 might be a good idea (take a look at the following bash code snippet) :

for((i=7824000; i<7824999; i++)); do
./extundelete /dev/sda6 --restore-inode $i ;
done

Viva !

I got 7 deleted files in this range (inside the RECOVERED_FILES directory), and one of them was my deleted python code ! And I spent my time on writing this article instead of rewriting the code 😉

Beautiful Nature

The fact that I always try to use open source softwares makes me to find new softwares and try them to see if they can solve my problems and do the job or not. Times ago, I had tried flashrom project to see if it can update my bios chip or not and the answer was NO ! Your chipset is not supported yet !

Later on, it was about May 2009 which I found a program which could change the boot logo of Phoenix bios images and I recalled flashrom. It was interesting that this time it said “Yeah, Your chip is now being supported! :)”. I made it to read my Bios image and the result was a real and valid phoenix image which I could change it. After making a new image, running flashrom to write it finished without any warnings or errors. I read the image again and Boom ! It was neither the original bios, nor the new one.

This is exactly where my first email went up online on the community’s mailing list and I knew that any invalid act which yields to rebooting the laptop is going to kill it. :

I tried the latest svn version (6 May 09) of flashrom and unlike older versions didn’t get a warning on my chipset. flashrom reads my chip successfully and outputs a fine Phoenix bios. After writing a new image into the chip

I found that writer is not fully functional and reading the chip again results in an image that is neither original one nor the new image. then I tried erase functionality and it resulted in some 0xFF and some unchanged bytes in the chip. Currently writing either images doesn’t change the chip and it remains in mostly 0xFF bytes.

Most of open source project maintainers use IRC as their collaboration and communication channel both with themselves and community. I went online and Peter one the maintainers was online but he wasn’t the person responsible for ICH7 series chipsets, So I had to wait for Carl to come online. It was midnight in Iran and I went to bed leaving the laptop up and running. Next morning I found Carl and after working with him to find the problem, he suggested to try AAI type of Chip-Programming. It was a time consuming task and I had to go for an important session, So I left home.

When I returned back, I got no good results of AAI. The wonderful part of story is that my little sister had played with my laptop, when I was out, and didn’t power it off, so that I don’t get noticed she touched my laptop without permission. 😀

Carl reviewed the data-sheets for my Bios chip and found that It doesn’t support writing multiple bytes at a time. Finally he sent me some patches and the last patch wrote the image successfully. I worked a few more hours to finalize the patch and sent some verification emails so that Carl can commit them to the main version tree (And got acknowledges for helping to track down the bug ! 😉 ).

It was an amazing experience of active community support and I should really thank Carl-Daniel Hailfinger, Peter Stuge and all other active maintainers of open source projects.