Using the KDE4 GUI (on a regular Ubuntu Unity desktop), the log prints (at least some) Scandinavian characters wrongly. I’ll attach a screenshot for demonstration. Meanwhile, the log viewer of the Gnome GUI displays the same characters without problems (I’ll attach a screenshot of that as well).
jani@saegusa:~$ apt-cache policy backintime-kde4
backintime-kde4:
Asennettu: 1.0.36~precise
Ehdokas: 1.0.36~precise
Versiotaulukko:
*** 1.0.36~precise 0
500 http://ppa.launchpad.net/bit-team/stable/ubuntu/ precise/main amd64 Packages
100 /var/lib/dpkg/status
jani@saegusa:~$ locale
LANG=fi_FI.UTF-8
LANGUAGE=fi:en
LC_CTYPE=fi_FI.UTF-8
LC_NUMERIC=”fi_FI.UTF-8″
LC_TIME=”fi_FI.UTF-8″
LC_COLLATE=fi_FI.UTF-8
LC_MONETARY=”fi_FI.UTF-8″
LC_MESSAGES=fi_FI.UTF-8
LC_PAPER=”fi_FI.UTF-8″
LC_NAME=”fi_FI.UTF-8″
LC_ADDRESS=”fi_FI.UTF-8″
LC_TELEPHONE=”fi_FI.UTF-8″
LC_MEASUREMENT=”fi_FI.UTF-8″
LC_IDENTIFICATION=”fi_FI.UTF-8″
LC_ALL=
The issue went away when I removed gnome-user-share (sudo apt-get --purge remove gnome-user-share
). Apparently it was caused by Gnome’s file sharing function referring to $XDG_PUBLICSHARE_DIR and recreating the (default-named) directory when not found. With gnome-user-share removed, the ”Public” directory no longer reappears.
I’ve set ”enabled=False” in my /etc/xdg/user-dirs.conf which, according to comments in that file, and also according to the spec, should stop xdg-user-dirs-update from running at login time and thus also from recreating any missing $XDG_*_DIR directories.
Additionally, I’ve commented out the definition of XDG_PUBLICSHARE_DIR in my user’s ~/.config/user-dirs.dirs due to not being able to decide where to point it at for now.
Despite xdg-user-dirs-update being disabled, a directory named ”Public” reappears in my user’s home directory at every login. What is causing this and how can I stop the unwanted Public directory from appearing? I’ve found an old Red Hat bug referencing a similar issue, but it’s closed without a known fix.
The issue doesn’t occur for $XDG_TEMPLATES_DIR which I’ve similarly commented out.
Also affects 12.04 (with gedit 3.4.1-0ubuntu1).
When the selected/renamed file is a directory: see Bug #1105232.
Is there an error in Gnome’s percentage? Currently it’s 14.1% which should make it #2 on the list.
Sebastien, I think this may be related to the patch applied to fix Bug #1085320: the Gnome folks have since reverted (at least parts of) it (see Gnome bug 688808 [1]) because it caused custom icons to be shown as thumbnails, hence the borders reported in this LP bug. I tested this by applying the changes in [2] to current Nautilus in Raring (1:3.6.3-0ubuntu16), and the borders around my customized icons went away. Also, though I didn’t test very extensively, this didn’t result in desktop files again having borders as originally reported in #1085320.
(The commit log entry of [2] refers to [3], but I think it should refer to [4] instead.)
*[1] https://bugzilla.gnome.org/show_bug.cgi?id=688808#short_desc_nonedit_display
*[2] https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-6&id=f69e472263b0bf6e1cc60c0eeaf7874fc7931f8d
*[3] https://git.gnome.org/browse/nautilus/commit/?id=d9ef715ea11e92917414d5d7bddd4dd1487fac1b
*[4] https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-6&id=6cde4c5a6d639c85df09b8992a307f91d6b056a6
At least for Ubuntu users, I recommend filing those bugs on Launchpad. The package maintainers are usually able to tell pretty quickly if the issue is an upstream one, in which case you then file it upstream (in Gnome’s bugzilla) and link the two reports (there’s built-in functionality in LP precisely for this purpose). When the distributor’s tracker is your first port of call, you won’t (usually) be bothering upstream unnecessarily with distro-specific issues.
In fact, I sometimes file bugs on LP even when I know the issue is an upstream one, and then just link the reports right away. This way other Ubuntu users, who can’t tell the difference and would file the bug on Launchpad anyway, are saved the trouble.
Not reproducible in current 12.10 with gdm 3.6.0-0ubuntu4, still reproducible in 12.04 with gdm 3.4.0-0ubuntu15.
Apparently this is now supported; at least the following seems to work under 12.04:
$ qdbus org.gnome.Nautilus /org/gnome/Nautilus org.gnome.Nautilus.FileOperations.CopyFile "file:///source/directory" "*" "file:///destination/directory" ""
where /source/directory is the absolute path to your source directory, * is the glob for file[s] to copy,/destination/directory is your destination directory and the last ”” is for destination file name. Note that you need to have the last one there even if it’s empty as in here, to fulfill the method signature. Also, if you specify a target name and have multiple source files, they’ll all get copied to that one destination file, giving an overwrite prompt for each file after the first one (which may or may not be what you want).