On Sun, 06 Dec 2009 15:39:54 -0800 Dale Snell <[email protected]> dijo:
>On Sun, 06 Dec 2009 11:30: -320800 >John Jason Jordan <[email protected]> wrote: > >> Thanks for all the suggestions. I finally nailed it. >> >> The ~/.local-original/share/applications folder for the new user had >> only two files. My ~/local/share/applications folder has many >> entries. I don't know what they do. Some appear to be part of the >> Applications menu, but others clearly are not. And I also have >> launchers in Applications that are not reflected in a file in this >> folder. >> >> However, I was especially interested in a file called >> metacity.desktop. I noted that the new user's original folder did not >> contain this file. I tried to rename it, but Nautilus would not let >> me. I certainly own the file and have rw permissions for it, but >> Nautilus just wouldn't let me. No matter, as root from the command >> line I renamed it metacity.desktop.old. Then I rebooted. And after >> logging in metacity launched as it is supposed to. Everything else >> seems to be working normally. >> >> I have no idea what rogue process created this file. >> >> It is a text file that can be opened with Gedit. Looking at the >> contents I see nothing that says "don't launch metacity for this >> user." >> >> If any of the Gnome users on this list have such a file, it would be >> interesting to compare notes. I feel an obligation to file a bug >> report, but I in order to make the bug report useful I need to figure >> out what is the purpose of the file, what created it, and where it >> went wrong. >> > >John, > >I do have the ~/.local/share/applications folder, and the metacity file >is in it. It's a simple text file. The contents are: > >[Desktop Entry] >Version=1.0 >Encoding=UTF-8 >Name=Metacity >Type=Application >... ><many lines of the form "Name[<language-specifier>]=Metacity"> >... >Exec=metacity >NoDisplay=true >X-GNOME-WMSettingsModule=metacity >X-GNOME-WMName=Metacity >X-GnomeWMSettingsLibrary=metacity >X-GNOME-Bugzilla-Bugzilla=GNOME >X-GNOME-Bugzilla-Product=metacity >X-GNOME-Bugzilla-Component=general >X-GNOME-Autostart-Phase=WindowManager >X-GNOME-Provides=windowmanager >X-GNOME-Autostart-Notify=true >Name[en_US]=Metacity > >Nautilus shows the filename as "Metacity", but ls shows it as >metacity.desktop (note the capitalization). Changing the name from the >command line (mv metacity.desktop metacity.desktop.orig) changed the >name as shown by ls. Nautilus, however, still showed it as Metacity. >Changing the name with Nautilus, to Metacity.orig, showed the name >changed there. Just to be stubborn, ls showed the name as >metacity.desktop.orig. A little digging showed what is likely the >reason. > >The last line of the file is "Name[en_US]=Metacity". If I change the >filename using Nautilus, that line changes to >"Name[en_US]=Metacity.orig". The actual filename, as shown by ls, does >not change. It seems pretty obvious that this line is what Nautilus is >reporting as the filename, at least on my system. > >Now, as to why Nautilus didn't want to let you change the name of your >file, I'm not sure. Check the SELinux context for the file, that may >be a problem. For that matter, check the context for the parent >directory. I've had trouble occasionally where I couldn't change a >file, even as root. The security context turned out to be the >trouble. Here are the directory listings from my system: > >[da...@valeron applications]$ ls -d --context ../applications >drwxr-xr-x dales dales unconfined_u:object_r:user_home_t:s0 ../applications >[da...@valeron applications]$ ls --context metacity.desktop >-rw-rw-r-- dales dales unconfined_u:object_r:user_home_t:s0 metacity.desktop > >Now that I think about it, SELinux contexts could be a problem waiting >to bite you. If you're bringing files into Fedora from another distro, >they almost certainly don't have the right security contexts, assuming >that they have any at all. Nautilus can set the contexts for you. >Move to your /home directory and right-click on your user directory. >Select "Properties" and select the "Permissions" tab. Make sure that >your folder and file permissions are set correctly (they probably >are). Then, at the bottom of the panel, you'll see a line "SELinux >Contexts" and a string widget. Make sure the settings are right >(again, they probably are, but if not see mine, above), click >the "Apply Permissions to Enclosed Files" button, and you should be >good to go. The string widget on my Nautilus is just a drop-down, but "User home directory" is what it was set to. I did click on the Apply Permissions to Enclosed Files button, on general principles. I have brought in only a handful of config files from other distros - .openoffice.org, .scribus, .rhythmbox, and the like. But no config files relative to the desktop or OS. Having said that, I have copied several dozen GB of data from my old Ubuntu disk. These are just data files. The interesting thing is that I did so by dragging and dropping with Nautilus. And I got constant error messages about lack of permission. The interesting thing is that it was always certain kinds of files, but not always. For example, when dragging a folder containing files for books on Mani and Kim that I did for a PSU professor, I could copy some PDF files, but not others; some TIFF images, but not others, etc. I kept looking for a pattern, e.g., were the non-allowed PDFs files that I did not create myself? But there was no obvious pattern. >That said, I *strongly* suggest reading up on SELinux. I found the >man pages to be dry and rather rough going, but their info is good to >have, since Fedora uses SELinux as part of its security setup. >O'Reilly has a book on SELinux which is easier reading than the Linux >man pages. > >Anyway, I hope that helped. It does, although it gives me a lot of work to do. :( _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
