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.

The XDG specified directories, as described by Jacob, are not created with the account, they’re created (and recreated if missing) when the user logs in. Pointing those user-dirs variables at $HOME is a workaround, but it doesn’t actually disable the functionality; if disabling is what you want, you can change ”enabled=True” to ”enabled=False” in /etc/xdg/user-dirs.conf. As the comment in that file above the definition says,

# This controls the behaviour of xdg-user-dirs-update which is run on user login
# You can also have per-user config in ~/.config/user-dirs.conf, or specify
# the XDG_CONFIG_HOME and/or XDG_CONFIG_DIRS to override this

As I explained in the Edit paragraph I added, the ”solution” was more of the problem as I presented it going away (through related bugs getting fixed) than finding a path of steps to take.

Having just installed one this weekend, I can confirm that at least ML-2165 (the non-wifi, USB-connected one) works under 12.04.3, with suld-driver-4.01.17 installed from the SULD repository.

The ”Filing bugs when off-line” section of the bug reporting community help can be applied here:

First, on the target system, gather the information in a file:

1. For a bug report about a system crash:apport-cli -p <package name> --save bug.crash
2. For a bug report about any other issue:apport-cli -f -p <package name> --save bug.apport

You will need to answer a few questions, which will vary depending on which package the bug report is about. Relevant system information, including the package name, is then saved on the target system, in the current directory. The extension indicates if it is a crash report or another kind of report. If you decide to rename the report file, please keep the .apport or .crashextension.

When the file is ready, copy it to the system you intend to use for filing the report. There you can then file the report:

ubuntu-bug -c <apport_file.extension>

I know I can file a bug report on the local machine by running `ubuntu-bug`. But what about when I have a bug on another computer elsewhere so that it’s not convenient to get to it physically to file a report there? Can I use Ubuntu’s bug reporting tools to gather data about the bug remotely, transfer that data to my local machine and submit a bug report here with the data from the other system?

Okay, thanks for the advice Eric. I do intend to post here if I do come across a solution, so I’ll keep this open for now. Software updater in current releases looks different, so I’ll probably close this in any case once the next LTS comes around and I’ve upgraded.

Uh, except there’s no ”abandoned” alternative in the closing alternatives, and the question is still valid.

Never got Compiz to do the job, so I’m closing this as Eric suggested. FWIW, this devilspie script seems to work: (if (matches (application_name) ”^update-manager$”) (maximize))