21 September 2000 - previous September updates: 02 06 10 12 15 17 19 21 ; previous updates

1 - RAR_BK Archiver Project in ANSI C (Part 1)

RAR_BK is written in ANSI C and has no graphical interface.graphical interface. However, it is quite informative and it will tell you everything it is doing: what system command it is executing; what folder is archiving; what directories it created to replicate the structure to backup, etc...

RAR_BK - RAR Archiver Project in ANSI C (part 1)

As you can read on the 130700 ["building a high end machine"], my PC hosts 230 GB of data, and such an amount of information brings problems when it comes to backup time...

If you do the maths, 230 GB would require, at least, 362 CDROMs, if you were to dump everything to optical disks. Of course this is such an unreasonable number, that some strategies have to be followed and some options have to be made, when choosing what to do with all the data.

Some data on my PC is temporary digital video, which will later be edited, meaning that, to start with, NOT ALL of the 230 GB require backup. In fact, and going direct to the point, the BIGGEST problem in my backups are websites.

I surf the web A LOT and collect hundreds of websites for offline viewing. If you are a little experienced on web surfing, you should have noticed that some URLs can get quite big, in the sense of having many characters.

URLs with names with a string length over 128 chars are a problem to backup. The problem is bigger than many people think, or are even aware of...

For example, most CD Recording software won't warn you about the tech problems that can arise from building disks, with very long filenames. The software's silence happens because of the JOLIET file system, which is auto-selected and trusted, when such files are present.

Unfortunately, the 128 chars maximum *indeed* is a JOLIET limitation, and the disk's behavior will be a mystery, if you dare to force in files over the limit, as you'll probably get duplicate entries in the file system's allocation table.

So, it is easy to understand that a direct dump of HD files to CD, is not a good thing to do, when there are very long filenames involved. You probably figured it out by now, that if a direct dump won't do it, how about an indirect solution?

The indirect solution is to use an archiver, like WinZip or WinRAR, apply it to the website's folder on the HD, then burn a CDROM composed of ZIPs or RARs!! Of course!

The above solution really works, really erases the previous file system problems, but it also debuts two small difficulties:

#1) if you have many folders to archive, you'll have a boring time doing the archiving to each and all of them...

#2) if you later need to access the archives on a CDROM, you'll need to have an appropriate reader.

My biggest problem is #1. I have hundreds of websites on the computer, living in three different partitions, so I really would appreciate an automation to the process of archiving the whole stuff.

My first attempts on solving the automation issue, were on building some batch (.BAT) files that could interface with the command-line versions of the archivers. And this is where I made an option for WinRAR, instead of WinZIP...

Both WinZIP and WinRAR have a command-line interface, meaning that you can call them from the operating system's command prompt ("the DOS prompt, as some call it"), and thus write .BAT files for the job.

But WinZIP's command prompt version is BETA, and WinRAR's is not. WinRAR can also achieve better compression ratios that ZIP, and allows many more options. including one that comes handy for solving issue #2).

WinRAR does not only offer more features and greater flexibility, but also allows the building of SFX archives - those who Self eXtract, meaning that you won't need a specialized format reader, to unpack the contents of a CDROMs with archive files.

So, at this point, I have selected an archiver - WinRAR. But what about automation? Doing "manual WinRAR" to all the websites on HD would certainly be painful! But so would be writing appropriate .BAT files... why?

The (new) problem is that I categorized the websites on the HD ("computer science", "languages", "gaming", "newspapers"... and so on...), so, each category folder can hold a different number of sites, meaning that I would have to write a special .BAT file for each category folder. Boring.

My option was then to write a C program that could work from any folder and do what follows: - archive each sub-folder in an equally named RAR SFX archived, located wherever I choose.

For example, imagine I have a "gaming" folder, where the "delta_force_2" and "quake_3" sub-folders live. Suppose my software is called "RAR_BK". In order to auto archive the whole gaming folder, it should suffice to type "RAR_BK" at the command prompt!

Calling "RAR_BK" makes to computer form a list of the available sub-folders (direct descendants only), and then do the appropriate system call to an existing RAR archiver, in order to obtain the desired files, ready to be burned on HD!

In this example we would obtain a "delta_force_2.EXE" file (EXE because it is self extractable) and a "quake_3.EXE" file.

The principle is really quite simple and useful. This automated archiver can be used to archive everything - not only websites! - to wherever mentioned.

I decided to write the software in ANSI C, because of some C characteristics:

- C code is portable to ALL platforms where you have a C compiler (all operating systems, literally);

- C interfaces greatly with the operating system (it is terribly easy to call any archiver);

- it won't hurt a bit to build a Windows interface on top of the C code;

So this was my answer, to my websites backup problem. The software is up & running, in a more general fashion than first expected.

In fact, what was built, was a "general purpose folder action caller", because what the software does is:

- form a list of the folders on the directory level, from where it is called;

- apply a you-name-it batch string to all the elements in the list;

Because my batch string is a RAR call, the software translates in a auto archiver.

LISP (the language) would have a wise choice too, since it has built-in list mapping functions.

Check this article's conclusion on 230900, from where you can download the source code and the executable.

These contents are also available from the Tutorial Section, as a C tutorial.

Since RAR_BK is really nothing more than a command-line front-end to an archiver of your choice (WinRAR was my option), it launches the selected archiver, when working. The picture shows a session of WinRAR, called by RAR_BK.