I'm having a problem with the Konqueror web browser. I'm using Mandrake 8.2 on an AMD K6-2 400, w/ 128 MB RAM. My internet connection is an external serial v.90 modem.

When using the Konqueror browser to surf the web, and for one user account only, the browser locks up and also shortly thereafter, causes the machine to crash and reboot.

I have another user account which works fine, and obviously I'm not hooking up to the internet while logged on as root. Also, other browsers work fine as well, even for the effected user account (in fact I'm on Mozilla 0.9.8 right now within that account). It's only for that one user account and for Konqueror that it crashes.

I've tried deleting some of the settings within .kde to see if there was something corrupted that was causing this, but it didn't help. I can use Konqueror just fine for browsing files and for browsing html files that are local. This only happens when connected to my ISP.

Can anyone help???

Nobody knows???

Apparently this is being caused by kio_http, but for some reason, I can't delete the cash. Every time a attempt to, the system reboots...

It is true whether I attempt to delete it from the original user account, root, and Xwindow session or an init 3 session.

I'm wondering what is causing this.

Does anyone know how to force a file to be deleted or at least force the system to check the partition for errors, in case this is just a case of file corruption???

fsck can run, it is like scandisk

Oh yeah, I just reread. I would deete the whole .kde in that user's home directory. It will start over next time you log in

You don't understand,
I already did that,...

Deleting the whole .kde subdirectory was not possible, when the rm command implemented by the file browser got to the bad data, the system would reboot. I couldn't even view the bad data, lest it rebooted the machine or locked it up. I believe it was taking advantage of an error in ReiserFS with long filenames. Apparently with a long enough filename, it can cause a DoS attack on the system and shut it down. If the system does not go offline, then a hacker could theoretically use the DoS to try and gain root on the system.

I don't know if it was just a bad data stream (the "data puree" problem that exists in reiserFS) or whether it was an intentional attack, thinking I was a server or something.

What I had was a file remenant from the old .kde in the .Trash file

I "solved" the problem by copying all but the .Trash bin (where I had moved it) out of the partition and onto a secondary drive to hold it. Then I reformatted the whole partition and moved the data back, then fixed the permissions in the directories...

However, this doesn't solve my problem about what I do if this ever happens again, and I don't have a spare drive big enough to hold all the data,... like I might if I start using wine or wineX to install Windoze software.

did you try rm -rf /home/username/.kde as root from the console, no X? Data puree happens when you have a lot of small files on a ReiserFS because Reiser can allocate "tails" of files to use the same inode to save space, but if a lot of these tails get saved to a variety of inodes Reiser looses track of where the "tail" of the correct file was saved and messes everything up.
I dunno anything about Reiser not supporting long filenames. AFAIK Reiser supports up to 256 character filenames like any other decent fyle system....
Also next time you can boot your system with a rescue disk/cd-rom, mount your partition under /mnt on the rescue system and rm -rf /mnt/home/username/.kde and it should work without problems. Am i making sense?
Hope that helps
-NSKL

I had tried deleting as root in console (init 3, not just a shell), as the user, etc., etc. etc.

The only solution was reformating the partition. As an interesting note, after I did, I transfered the files back to what I thought was the partition, but in fact was a directory on the root partition. I backed up then fixed the problem.

The filename size susceptibility in reiserfs has been documented,...
try a google/linux search on it,... there's not a lot on it, but it does exist.

Whether it has ever resulted in a security breach is another thing.

i got around a problem i had with kio_http by reinstalling the kdelibs3 package, to the newest from kde.org. once i did that kio_http was found again.