SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Hi friends - haven't been on Linux for over a month but something strange has happened. In Konqueror (under KDE 3.2.2), whenever I click on a folder/directory/share icon - anything, I get the following message: "Sorry - KWrite: the file "file:/opt could not be opened, it is not a normal file: it is a folder." Which of course is exactly correct, it is a folder and I want to expand it, and NOT have KWrite invoked, opening a blank KWrite window. It seems every Folder has been somehow associated with Kwrite. and I need to dis-associate this. Of course, I don't remember changing anything this drastic <g>..really, I don't.
Something has gotten completely messed up with Associations here, and I am sure that this is a trivial thing that has somehow been accidentally changed. I can't figure out how to undo this damage from Setting, Configure, Associations. ,,,,
All help appreciated here, thanks.
Look in the KDE start menu thing for something called KDE components, then look for File Associations under there. That is where you can associate .jpg with Gimp etc etc etc.
You may can also right click and select open, then tell it to open with Konqueror as well. If you google around, you may can find where the file associations are kept and just rename it then restart KDE. It should restart with a default file. I messed mine up once and I just did this:
rm -rf /home/dale/.kde/*
You can also just rename the directory to .kde.old or something just in case you need something back out of it, or it doesn't replace it like it should.
Maybe someone will come up with something better. It is easy to add a file type but hard to find and get rid of a bad one.
dalek - thanks, but I wonder if its "safe" to just wipe out my .kde directory....I realizing taking a backup is pro-active but I figure there must be some setting I have inadvertently change??? Perhaps I could try and copy the desktop settingsa from one of the other userids I use (like root)?
I have done that before. KDE looks and if it is not there, it makes a new one with the defaults. You can rename it to .kde_old and then try it. If it don't create a new one, then you can just change it back to .kde and carry on.
You can just make a new user and login to the new user, which will create that new .kde directory, then copy it over.
I'm 99% sure it will just create a new directory though. I know when I first installed KDE during my install and was in command line, I didn't even have my /home partition mounted at the time.
There is more than one way to "skin this cat" though. If you are worried, just make a new user, login, then copy it over. You can even use Konqueror to copy it over, as root of course. Also, make sure you change the permissions and ownership to the new user. If the permissions are wrong, it won't work.
From this I made the list (FILES) of the files whose time stamps indicated they had been changed by Konqueror's configuration.
(In an xterm, I used Alt-Ctrl-drag to select the column of filenames. I pasted them into a text file & built the FILES="..." command there. Then I pasted it back into the xterm, where it executed beautifully, thanks to the escaped newlines.)
I then executed the following series of commands (not as a script):
# make a file list
# make baseline files
for F in $FILES; do cp $F $F.01; done
# Reverse the change in Konqueror's configuration
# check for differences
for F in $FILES; do echo $F; diff $F.01 $F; done
# display the interesting differences in a nice format
diff -u10 \
# go change the configuration back
# remove the filelist & the baseline files
for F in $FILES; do rm $F.01; done
Useful aside for new folk
all mean the same thing -- 1 & 2 expand to 3.
Last edited by archtoad6; 06-25-2006 at 09:25 AM.
Reason: fix bad list tag
arch and tk - let me look at both your proposals....
P.S And I will not cross-post...it just seemed to me after a while that this question was not Slackware specific (indeed, had nothing to do with SW, but KDE, and an optional front-end at that), so I put it over in the newbie forum, bit now I am back here.
tkedwards - I have done what U suggested... KDE Control Centre->KDE Components->File Associations and select inode->directory
and have found the following:
Konqueror, then followed by Cervisia.
Clearly you are saying the latter should not be there. Do you think this is responsible for the problem I have described. Obviously it is easy enough to remove the entry, if it is erroneous....
Let me be more precise in my reply. As user "root" - a user that did not have the described problem - the Associations for inode-->Directory were Konqueror and Cervisia in that sequence.
As a user for which I had this problem, KWRITE was at the head of the list (followed by the same two entries as above)!!!!! So it is hardly surprising that KWRITE constantly got invoked on mouse click. How it got there, I can't say, and perhaps it doesn't bear further analysis. In any case, I promptly removed it, and the system seemed to behave more "normally".
So many thanks for that.
I guess I have to ask the (not so obvious) question, what is the significance of the inode-->directory File association (which may or may not get into a discussion of inodes in Unix-based file system management ........)
the Associations for inode-->Directory were Konqueror and Cervisia in that sequence.
Cervisia is a CVS client so it would make sense that its in the list, as long as its not first. You may find it useful one day so I'd leave it there.
hat is the significance of the inode-->directory File association
Its just what it appears to be - the setting for which program opens a directory by default in the KDE desktop environment, nothing more than that AFAIK. As for why its called 'inode->directory' I'd guess that that's just the convention that has been chosen. An inode exists for every file and directory on a Linux file system so it makes sense to call it 'inode'.