Shuva's blog
Hack : RAID-0 (Mirroring) support on your Windows XP Box  
Saturday, October 27, 2007, 09:35 AM - Tips and Tricks
I do a lot of photography and I have always been afraid of losing my images. What I am most afraid of is a hard drive failure more than anything else. Those large images will be gone forever. Taking regular backups on a separate drive is a good solution, but maintaining the backup software and updating it regularly is not a sustainable idea for me for a long term.

RAID is a scheme at the hardware level that divides and/or replicate data among multiple hard drives. There are 3 basic concepts in RAID:
mirroring, the copying of data to more than one disk;
striping, the splitting of data across more than one disk; and
error correction, where redundant data is stored to allow problems to be detected and possibly fixed (known as fault tolerance).

If you have multiple hard disks to RAID, it can either be achieved via hardware or software. Hardware RAID is quite costly for a home user like me.

Of the different RAID types(levels), RAID-1 (also called mirroring) which takes a minimum of 2 disks to provide fault tolerance by writing the same data into two disks is a very good replacement for automatically taking backups of my precious pictures.

Windows XP (which I use) apparently does not support mirroring of disks. It is supported only on Windows 2000 Server, Windows 2000 Advanced Server, or Windows 2000 Datacenter Server. The how-to link from Microsoft is here.
If you try following these instructions on your Windows XP box, you will see that the options to support Mirroring are not available.

I came across an article on Toms Hardware (whose link I cant find currently) which said that RAID-1 support on Windows XP is actually only disabled. To make it working you need to edit 3 files and reboot your system. I have been running this mirrored setup on a two 500GB SATA hard-disks for more than a year now without any issues.

The three files that you need to edit are:

C:\WINDOWS\system32\drivers\dmboot.sys
C:\WINDOWS\system32\dmadmin.exe
C:\WINDOWS\system32\dmconfig.dll


Now the most important points on how to do this:
1. Take a backup of these files first. Microsoft does not support this and so you are doing this at your own risk. In worst case, you can go to the Windows Recovery Console by booting with your Win XP CD and replacing them.

2. You need to hand edit these 3 files using a Hex Editor. If you dont already have a good Hex editor I would recommend Cygnus Hex Editor FREE EDITION.

3. After editing, you just cant replace these files by copying them. Windows XP wont let you replace system files just like that. Keep the edited files somewhere and boot your system using the Windows XP CD and enter the Recovery Console. Its now when you can replace the 3 system files.

4. RAID-1(mirroring) is now enabled on your system. To mirror two hard drives, follow the instructions as described in the Microsoft Product documentation.

5. If you are every updating your system be careful to make sure those updates dont touch these files, else you will need to repeat these steps again. In short, once you do something into your system which is not officially supported, you are on your own.

Once you have mirrored two drives, you would see only 1 drive in place of the two in your Windows Explorer. I named it the M: drive. I copied some data into them. Then I manually broke the mirror, deleted the contents of one of the disk to simulate a disk failure. Then when I connected the disk back(its like connecting a new disk) and reconfigured the mirror, it replicated all the data into the new disk. It works!

So what are the changes in those 3 files that you need to hand edit. You need to search for certain hex patterns and replace them. Here are the screen shots of the differences of the 3 files. Each screen shot below shows the section of the original file which needs to be edited (with the hex pattern highlighted) with the changed file section below it.

1.C:\WINDOWS\system32\drivers\dmboot.sys


2.C:\WINDOWS\system32\dmadmin.exe


3. C:\WINDOWS\system32\dmconfig.dll


The above screen shots are of Apt Diff, a free software.

Does anybody know if Windows Vista support mirroring? I tried looking at the features but could not find, but did not look(or google) hard enough.

Happy RAIDing.//
6 comments ( 4731 views )   |  0 trackbacks   |  permalink   |   ( 2.9 / 58 )
Unistalling GNU source compiled programs 
Sunday, October 21, 2007, 06:22 AM - Design concepts
If you have downloaded GNU based Open Source programs and built on your UNIX box, you must be familar with the

./configure
make
make install


sequence of commands. The last step copies all the binaries (executables and libraries) and optionally man pages and header files into the proper places on you system. It can also be moving and deleting files, changing file permissions here and there. The big question now comes -- How do I uninstall this software? You want to be doing the exact reverse of what happened during install. Unfortunately the GNU configure/build/install framework does not make it mandatory for software developers to supply an uninstall script. So you end up leaving your installation a bit dirty. Many people say "What else do you expect from free software?".

To be more detailed, the last step make install executes the command "make" which is an ELF executable which loads the shared library ld-linux.so (or just ld.so on BSD variants) and libc.so. The behaviour of the dynamic loader can be controlled by an environmental variable called LD_PRELOAD. This instructs the loader to load additional libraries into a program, beyond what was specified when it was compiled.

Keeping in mind that file-system related system calls like open, fopen, unlink are defined in libc.so, it should be possible to write a custom library that overrides these system calls by inserting a filter before actually calling the real call. Inserting a properly formatted log messages just before calling each of the file-system syscall is enough to keep track of what modifications the command make install did to your system. These log messages are sufficient information to uninstall the program which you just installed.

This is precisely what the Installwatch does. Now here's the Installwatch's description written by it's author.

Installwatch is an extremely simple utility I wrote to keep track of
created and modified files during the installation of a new program.

It's fast and easy to use. It doesn't require a ``pre-install'' phase
because it monitors processes while they run.

Installwatch works with every dynamically linked ELF program,
overriding system calls that cause file system alterations. Some of
such system calls are open(2) and unlink(2).

Installwatch is especially useful on RedHat, Debian and similar
distributions, where you can use a package system to keep track
of installed software.

Of course a simple `make install' does not update the package database,
making your installation ``dirty'' -- well, kind of.

If your room is a mess but you make RPMS even for your home directory,
then installwatch is for you.


The entire source code is a single file called installwatch.c. Some extract from some important functions are here:

In the _init() function :

...
...
libc_handle = dlopen(LIBC_VERSION, RTLD_LAZY);
...
...
true_creat = dlsym(libc_handle, "creat");
true_fchmod = dlsym(libc_handle, "fchmod");
true_fchown = dlsym(libc_handle, "fchown");
true_fopen = dlsym(libc_handle, "fopen");
true_fopen = dlsym(libc_handle, "fopen");
...
...

And one of the system call open() is filtered as shown below:

int open(const char *pathname, int flags, ...) {
/* Eventually, there is a third parameter: it's mode_t mode */
va_list ap;
mode_t mode;
int result;
char canonic[MAXPATHLEN];

REFCOUNT;
va_start(ap, flags);
mode = va_arg(ap, mode_t);
va_end(ap);
canonicalize(pathname, canonic);

#if DEBUG
printf ("open\n");
#endif
if(flags & (O_WRONLY | O_RDWR))
backup (canonic);

result = true_open(pathname, flags, mode);
if(flags & (O_WRONLY | O_RDWR))
log("%d\topen\t%s\t#%s\n", result, canonic, error(result));
return result;
}


As you see the heart of the idea is to override the file-system related calls with a custom call, which eventually calls the actuall libc.so defined call but not before logging all the information we want. Pretty neat na!

So coming back to uninstalling the GNU program, we need to understand the format of the log files. How about automating this? How about changing "make install" to built an RPM and use the information generated by Installwatch to build the unistall logic in the RPM.

This is precisely what CheckInstall does. If you have installed checkInstall (which comes with Installwatch packaged with it), then this is what you do to build your GNU programs from source.

./configure
make
checkinstall


checkinstall will internally call make install. It is an interactive program giving users to build RPM, Slackware or a Debian Package. Once the RPM is created you can install the RPM using the

rpm -ivh <rpmname> and now since the rpm database is properly updated, you can do a clean uninstall with
rpm -el <rpmname>

I came across this two beautiful piece of program when researching how to uninstall a program built from source. It is a must-have for me now.

I recommend you reading the FAQs on CheckInstall for special cases and unsupported stuff and common problems.

Idea:
If you already have software installed using the conventional make install method, you can still go ahead and use checkinstall to create an RPM package, force install the RPM (rpm -ivh --force <rpmname> and then uninstall it. :-)

Happing Uninstalling.//
add comment ( 263 views )   |  0 trackbacks   |  permalink   |   ( 3.1 / 56 )
Remote Desktop infinite loop attempt 
Thursday, October 18, 2007, 04:24 AM - Ideas and Thoughts
It was obvious that it wont work, but I just wanted to try it out before opening my C++ editor and starting the work for another day at office.

I tried to create a Remote Desktop loop.

Settings:
1. Start Cygwin and WindowMaker (your X) on my Windows XP box. (Dont forget the xhost +)

2. Start a Linux instance (VMware in my case) whose .bash_profile has the DISPLAY variable set to your Windows XP box. This means when you login into your Linux desktop, the display shows up on your X server running on your Windows box. Preety neat na!

3. Now start rdesktop on your Linux desktop. I got the login screen. Now try to RDP into your own Windows XP box. If this works I would be seeing an infinite loop of my own Windows Desktop --> GNOME -->rdesktop --> Windows Desktop --> GNOME ------->

I did not work and I got a blank screen and after a few shake of the mouse, my main Windows login login prompt showed up. Login again and your rdesktop's connection was reset.

But it was a fun try.//
add comment ( 287 views )   |  0 trackbacks   |  permalink   |   ( 3 / 61 )
The Alice and Bob story 
Saturday, October 13, 2007, 11:09 AM - Just a thought
If you have studied computer theory, I bet you must have come across examples where the persons involved are always named Alice and Bob. Ever wondered why? In geometry we used A,B to refer to two points. Is this because these are two names starting with A (Alice) and B (Bob)?

The The Alice and Bob After Dinner Speech given at the Zurich Seminar, April 1984, by John Gordon, by invitation of Professor James Massey is one of the most hilarious piece of textual material with a perfect aroma of computer theory examples that I have read recently. I cant resist myself from posting it here.

I suggest you to stop reading my blog now and jump directly into the speech. You will love it.

If you are still reading this blog, here are a few extracts from the long speech:

1. Over the years Alice and Bob have tried to defraud insurance companies, they've played poker for high stakes by mail, and they've exchanged secret messages over tapped telephones.

2. ...Alice and Bob have very powerful enemies. One of their enemies is the Tax Authority. Another is the Secret Police.

3. An intelligible joke in its raw form is called the Plainjoke, and after encryption is called the Cipherjoke or Cryptojoke. Cipherjokes are intelligible of course only after Decryption, or as some people call it, after explanation.

4. Very good jokes, the comprehension of which by outsiders could constitute a threat to national security, are encrypted much more securely, usually by completely changing the scenario, the plot and the conclusion. This is the PARTICULARLY KLEVER COVERUP or PKC. The best known PKC RESISTS SERIOUS ATTACK and is therefore called the RSA.

5. ..standards are being formulated whereby the nonstandard parts, which must conform to certain standards of non-standardization, are also to be handled only in a standardized nonstandard way in order to standardize on the overall non-standardization.

6. Consider the message: "Return home at once, trip cancelled." and think of the effect on world events if it had been decoded in time. It was sent in 1492 by Isobella of Spain to Christopher Columbus.

7. "You're the guy who beats up pocket calculators!"


Now I bet you cant resist reading the entire speech.
1 comment ( 120 views )   |  0 trackbacks   |  permalink   |   ( 3 / 56 )
ftell() issue : Cross platform compatilibity 
Friday, October 12, 2007, 05:16 AM - Programming
FILE *fp = NULL;
char buf;

fp = fopen("datafile", "r");
fread(&buf, 1, 1, fp);
printf("%d\n", ftell(fp));

return 0;


Here we are opening a file in read mode and reading off 1 character from the beginning of the file. We then print the current file position indicator. What do you think is the output? First guess is 1. This is always true if you run this program in Linux, but while in Windows, it depends on the contents in the file. Thats precisely where I and Naren hit the speed breaker yesterday.

In Windows, opening the file in "r" mode "generally" means that it would ignore special characters and read only text characters.

Lets create a file with the code as below:


FILE *fp = fopen("datafile", "w");
char i = 0;

for (i=0;i<32;i++) {
fwrite(&i, 1, 1, fp);
}
fclose(fp);


Here we are simply writing the first 32 characters from the ASCII chart into the file.

Our reader program would print 1 in Linux and 6 in Windows, which can cause nightmares for a cross-platform programmer.

After doing a little bit of MANing and MSDNing, I have two solutions:

1. Always open the file in "rb" mode, ie, fopen("datafile", "rb"). "b" in Windows means that the file is being opened in binary mode and so ftell() will not skip special characters. In Linux there is no such discrimination, but for the sake of compatibility the "b" character in the mode argument will be ignored.

2. If for some reason you dont(or cannot) change the mode in the fopen() call, you can still make Windows to read the file in binary mode by calling the function _set_fmode(_O_BINARY); just before the fopen() call. This tells Windows that the default file translation mode is BINARY. This call sets a global variable, _fmode, and so if you want to revert it back, you can do so by calling _set_fmode(_O_TEXT);

Happy Ftelling!!
add comment ( 104 views )   |  0 trackbacks   |  permalink   |   ( 2.9 / 51 )

<<First <Back | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | Next> Last>>