Today I have discovered serious problem in 7-Zip 3.13. This problem was mentioned as “leading space problem” on sf.net’s 7Zip forum somewhere in January’04, but it was not fixed until now. I was really surprised – usually open source products do have frequent releases, but… did it really were more than 8 months since the latest 7Zip release? Igor seems to be quite busy somewhere else.

The problem description is short: If you archive a hierarchy, and you have a directory, which starts with “space” (for example ” Test directory”), then you will suffer the following situation:
1. You will be able to create an archive, which contains this directory and the whole hierarchy behind it.
2. This archive will be tested OK, and you will assume that all is fine with it
3. However, the archive will **never** unpack, you will see the diagnosting message “can not open output file *FILENAME*” for all the files, which are in this hierarchy. And if you have used 7z format, you’re screwed.

I have reported immediately the problem to 7-Zip site. I hope the authors will react, because the problem is really dangerous, can lead to data loss, and it would be pity if such problems do not take enough attention.

It’s fear to mention also that Windows itself does not easily allow you to create a folder with space(s) as first or last characters. The GUI definitely keeps you out of this trouble. But the command line mkdir " This is with space before" works quite fine! And that’s most probably the reason for this bug – such situation is rare to happen.

Today Alexander Shopov was giving me some help because of a very severe problem I had here. The problem (already solved by magic – we did not noticed what exactly solved it) was that

rpm -qi kernel

was showing two kernel packages installed, but when I try to remove the older one, it was reporting that the package was not (?) installed. However, as I said – the problem was solved magically – after many tries, the last “rpm -e” command strangeously why succeeded.
However, this article is not about this. It’s about some nice rpm query commands that I want to remember. And the best way to remember them is to store them here :).
The first command to remember is:

rpm -qi <package name>

This command gives you valuable information about all installed package’s versions. If this this information is too much for you, and if you need the real package(s) names, in the way they should be given in probable “rpm -e” command, then you should use the second command to remember:

rpm -qa <package name>

This command enlists all packages with thie name (and their different versions). You may use the output as source of the “rpm -e” command later.
And during Alexander’s help, I learned the third command (mini-script) to remember:

for i in*; do echo -n "$i :: " && rpm -qf $i; done

If you run this mini script in given directory, it will list each file from that directory and the rpm, to which this file eventually belongs to. If the file does not belong to any rpm – you will have the corresponding message about it. Very useful thing indeed!
I would like to thank again to Alexander for all his time! I learned valuable things, and he also helped me (though I did not understood how finally it worked) to overcome my problem!

This article should continue my Linux lame articles, which I post here. I am starting to think to rename the “Hacking” category to “Lamer” :). Maybe later…

Today I had another Linux-newbie problem to solve. It’s simple, it’s newbie, and although I’m Linux user since 1994, I never had need to sove similar problems, or I never wrote my experience about such. So now I decided to write it here, and when I need it again after 5 years, I will just consult my blog ;).

The problem: I had to force SIM to erase some history files regularly. Usually, people just redirect the needed history file(s) to /dev/null, but strangeously why, my SIM-ICQ 0.9.3 was not able to accept such solution (**really** weird things started to happen with all accounts, which had their history files as links to /dev/null, so I quit trying that solution).
I had to create a script, and make it run each day on the morning. I wanted even more – I wanted cron to force all scripts, placed in given directory, to run at given time.
The really **big problem** was the fact that I was lazy to read! I wanted to solution right now in my hands, so I had to ask Veselin Kolev, one of the Linux gurus, for help. I know it’s a shame to waste experienced people time like that, but again, I was lazy to read, and Veso was online :).
He told me in few lines the solution. And here it is:

1. First, I had to create the folder in my home directory. I chosed the name “.cron”, because it was looking nice to me, and it’s a hidden folder – it would not bother me when browsing my home with Konqueror;
2. Now it was turn to make the script. So I did, I placed the script in that folder.
3. Now it was time for root access. I modified /etc/crontab – I added the following line to it:

   # `doncho` scripts
   00 6 * * * doncho run-parts /home/doncho/.cron >> /dev/null 2>&1

4. Now, all the scripts from directory “/home/doncho/.cron” will run each day at 6:00 AM.

During our conversation, Veso explained me how to use the “at” command for tasks, which I need to run once at given scheduled time. His brief explanations were:

1. You create a script, and place it somewhere. Example – the following script (named ~/download), which downloads some site at some dir:

   #!/bin/bash
   wget --directory-prefix=/home/doncho/dobwload http://nana_download_server

2. Now we must schedule the execution using the “at” command:

   at -f ~/download 23:00 05182004

3. This script will run on May 18th 2004 at 23:00
4. If the computer was switched off at that time, the script will run as soon as the computer gets up later, i.e. it would not be forgotten if the computer was offline when that time comes.

That’s all for today :). I hope you did not get too bored :).

My system: Fedora Core 2
A few days ago I was infront of a trivial problem, which I never solved before. I had to create some shared space (without quotas or other fancy stuff) on my Linux partition. I needed any user, who belongs to given group, to be able to have full control to that space.
I started with creating group ‘users’ and adding the needed users to it. After that (as root) I created the folder ‘/home/SHARED’, and I

chown -R root:users /home/shared

After that I logged on with another user (who belongs to ‘users’) and – whoops – it was not working. Permission denied. I double-checked the permissions, but all seemed correct.
I got mad. I though I *knew* these things – it should not happen like that. Maybe my madness stopped me from finding the solution of the problem right now, but I tried tons of stuff/experiments – and nothing! The other user could not write to that shared place! I got completely mad! If you would like to know how mad I was, just have in mind that I had crazy thoughts digging through the source of chown or chmod commands in order to understand how the permissions work :(. Fortunately, I did not started with that – I just went to bed. Before that I switched off the machine.
This morning – suprisingly, it worked! I still do not uderstand how and why (the hell) it needed that restart – maybe you could help me? But I was lucky – my friend Nikola Antonov was online, and I asked him that question. He supposed that the yesterday’s user should be logged off/logged on in order new permissions to be taken into account? I still do not believe that.
The fact is that now the shared space works fine. There was just one small problem, which Nikola showed me how to remove (and that’s why I decided to share in English my experience with you). The problem was that though it was shared space, if user A creates a folder, user B (both A and B are in ‘users’ group) cannot delete that folder if it’s not empty. If it’s empty – all works. That was because when creating the folder by A, the newly created object gets owner A:A, and not A:users. Invoking the command

chmod -R g+s

solved that problem too – now when whoever creates an object there, this object has as owner :users, which makes it fully accessible by all others.

Today Nikolai I. has sent to me this excellent article, which covers complete Linux filesystems’ benchmark.
I post it here for two main reasons:
1) To have it stored for the future (I decided to post all such useful material here)
2) To all my friends, who take care reading my blog aware of it.
The general quote, which this article leads to, is: do not use ext3 filesystem. Ouch, this is my filesystem at home :(. It seems I must change it soon!