handyfloss

You would think that, as a researcher in a serious center like the DIPC, one would hardly ever encounter a MS product, at least in the server/cluster section (more than one fellow here has Windows in his/her computer, but don’t tell anyone, it’s a secret).

However, we do have some server running Windows, and its presence is almost transparent for the user (which is good). And I say “almost”, because it stumbled upon one of its “features”, and the sysadmin ended up confessing :^)

The thing is that I happened to try to create a directory with “CO” (carbon monoxide) in its name (it was a dir for a SIESTA calculation), when a dir with the same name already existed, except it had “Co” (cobalt) in the name. Well, the filesystem complained that a dir by the same name already existed! I could not believe my eyes!!

Basically the filesystem would not make any difference at all for different capitalizations. For example:

<pre>
% mkdir testdir
% mkdir TESTDIR
mkdir: cannot create directory `TESTDIR': File exists

% touch testfile
% rm TESTfile
rm: remove regular empty file `TESTfile'?
</pre>

The explanation? The directory I was in was exported from a NAS running… ta-da: Windows 2000 Server!

How incredibly stupid and annoying is it to have a filesystem that ignores character case altogether? And how error prone? Because if you are not aware of that, you might delete a file you didn’t intend to!! Someone could try to excuse MS by saying that, OK, that was in 2000. But, look, Linux could tell upper case from lower case since its inception in 1991, and Unix since the seventies! The root of the problem is the filesystem used by the OS, of course. But it so happens that the filesystems used by Linux since 1991 (beginning in ext and then many others) had this capability (and many more), and are free. All that MS had to do was to use them, instead of FAT or NTFS. But instead they chose to develop those (inferior) filesystems in parallel for almost 20 years now. I call that stupidity.

No need to say that the sysadmin of the DIPC absolutely regrets having been naive enough to ever buy that MS crap.

One argument I tend to hear from Windows users is that in Windows you can do as much as you can with Linux, and that the technical advantages of Linux only show up if you are really an utter geek. This is one of (I hope) a series of entries in my blog, illustrating some cases where this doesn’t hold: I took advantage of tools provided by Linux in a way that anyone could have, not just geeks.

The moral of it all is that Windows encourages a lack of choice and flexibility that makes users tend not to be creative, and think the cage Windows keeps them in is actually a shelter from the storm, when it’s not. They think that what can’t be done with Windows, needs not be done. I think otherwise…

Today I will try to provide an example in which hard links can be useful. Under Windows XP hard links can be created, using the fsutil utility, but only for NTFS file systems, and only by the Administrator account (and only from the command line). If you want to learn more about links and specially Windows links, read this interesting sell-shocked.org article.

The problem

I download a lot of music from Jamendo, using the BitTorrent p2p protocol. After having downloaded a given album, I tend to leave the torrent open, so that people can continue uploading from my computer.

However, I also want to have my music collection tidy and ordered, so I immediately organize the newly-dowloaded songs moving them to a neat directory tree I have, will all my music.

So, there is a conflict between keeping the files in the bittorrent download/upload dir, and properly organizing them. I don’t want to have to wait until I decide to stop sharing a file to organize it, and I don’t want to risk deleting the files if I remove them from the bittorrent client before saving them elsewhere. I could get over all this by simply making a copy of the files… but then I would be filling twice as much disk space, and with GBs of shared files, this is not neat at all.

The solution

What I do is hardlink all the downloaded files to their final location. If I download all torrents to /scratch/ktorrent/, a downloaded album will look like that:

% ls /scratch/ktorrent/album1/
song1.ogg song2.ogg song3.ogg [...]

If I want to save the album under my artist1 directory, I do the following:

% mkdir /scratch/music/artist1/album1
% ln /scratch/ktorrent/album1/* /scratch/music/artist1/album1/

This way all the “song*.ogg” files will appear to be in both /scratch/music/artist1/album1/ and /scratch/ktorrent/album1/ at the same time.

Benefits:

1 – I can keep sharing the files in /scratch/ktorrent/album1/, while listening to and/or manipulating the /scratch/music/artist1/album1/ files as if I had 2 copies of each.

2 – The total size is not affected. The hard links do not “occupy” space (only a few bytes each).

3 – I can delete the files in the shared directory without any fear. Only the “copy” in /scratch/ktorrent/ disappears, while the other “copy” in /scratch/music/artist1/album1/ becomes the only copy (just as if it had always been a “normal” file, and the only one).

Recall that all files are hard links. Normally a given file is the only hard link to a given piece of data in the hard disk, but there can be more “links” pointing to that data. When we remove files, we only remove the “link” pointing to the data.