I use two Plasma Activities, each having 9 VDs. The primary Activity is my “daily driver”; here i do all my day to day playing around, browsing, documents, music streaming etc. Its desktop is set to Desktop Layout. My secondary Activity is less visited, typically only weekly. It’s my “administrative” area, with lots of system info widgets on the desktop [which is set to [i]Folders Layout]. I switch to this Activity when i do my weekly +/-] zypper dup.
Sometime since the previous dup, ie, sometime in the past ~week but i can’t narrow it down better, two new & unexpected folders appeared on the desktop of my secondary Activity. I did not knowingly put them there, & i’d prefer them not to be there. Obviously i tried removing them, but then i discovered they’re owned by root. Before i force their deletion using root privileges i felt i should pause & first ask here, in case i’m about to create trouble for myself.
Has anyone seen these folders appear on their own desktops, have any ideas about why they occurred, & have any comment about the safety in me now deleting them, pls?
I am not seeing those. It is probably caused by something that you did.
I would guess that the “@$System” folder is from Yast, probably while running Yast Software Management. And the reason I’m guessing that, is the “@System” is used to indicated the list of all installed packages. Hmm, “zypper” also does that. So maybe it was something that you did in “zypper”.
In any case, what you see on your desktop (apart from wallpaper and windows) comes from the “Desktop” directory (under your home directory). You can go there with a command line (perhaps running “konsole”) using
cd ~/Desktop
And then if you list the directory
ls
you will see subdirectories “@System” and “zypper” which will be those new folders. Since they are root-owned, you would have to remove them as root. Since they are readable, you should be able to list their content without being root:
ls @System
ls zypper
I’m pretty sure that your normal desktop menu will have an entry for “File manager - super user mode”. You might find it easier to use that.
And definitely take a look at what is in those folders before you decide whether it is safe to remove them.
Yes whilst it’s pretty sure that these 2 directories came into recent existence due to some action i did, i’ve still no idea what it might have been [given i’m not aware of having been doing anything radical / new / different in the past week compared to before]. Anyway…
Yes, “zypper” is really empty, those “.” and “…” files are just placeholders to navigate up-down the file tree.
The usual place for “@System” is /var/cache/zypp/solv/@System; if you have a valid content there, removing the “fake” one should be harmless; anyway, as tannington suggested, just rename it and see what happens. Anyway, the content being just the results of the zypper solver, I think that zypper will recreate those at the right place on the next invocation.
Just a wild guess about the causes, maybe you invoked “zypper” (or Yast2-Software) in some non-usual way; maybe by typing just “su” instead of “su -” in a terminal while pointing at your Desktop just before invoking “zypper”?
gooeygirl@linux-Tower:/var/cache/zypp/solv/@System> **ls -lah**
total 3.6M
drwxr-xr-x 1 root root 36 Oct 26 13:13 .
drwxr-xr-x 1 root root 414 Oct 26 13:14 ..
-rw-r--r-- 1 root root 52 Oct 26 13:13 cookie
-rw-r--r-- 1 root root 3.5M Oct 26 13:13 solv
-rw-r--r-- 1 root root 116K Oct 26 13:13 solv.idx
gooeygirl@linux-Tower:/var/cache/zypp/solv/@System>
I’ve never [knowingly] done “su”, & it’s a very long time since i last did “su -”… i virtually always use just “sudo”. So this remains a mystery for me.
Anyway, i have now temporarily renamed them both, & if nothing explodes or disintegrates before the weekend, i shall then delete them.
Thanks again to all who’ve helped [such a great community here].
UNIX® and Linux usually have a strict separation of User and System directories.
Therefore, it may pay to, with the user ‘root’, to “grep” everything in “/etc/”, “/var/”, “/tmp/”, “/usr/”, “/opt/”, “/root/”, “/bin/”, “/sbin/”, “/lib/” and “/lib64/” for a string looking like your user home directory.
A directory named “zypper” is only in the “/usr/lib/”, “/usr/share/” and “/usr/share/doc/packages/” system directories on this machine. With the user ‘root’: “find / -name ‘zypper’ -type d” ]
Thanks. Well now there’s a mystery in a mystery… i cannot argue with those dates/times you noticed, given they’re there in black & white… but, i simply did not notice those two directories on my desktop before a week ago [or less]. Furthermore, the log gives no insight either, completely skipping over that timestamp:
2017-09-28 18:50:55|install|mariadb|10.1.25-2.1|x86_64||download.opensuse.org-oss|29e7ad0c7d48673d92316cc28164f176dea11a3c|# 2017-09-28 18:50:55 libsoftokn3-3.32.1-1.1.x86_64.rpm installed ok
# Additional rpm output:
# /sbin/ldconfig: /usr/lib/libbrcolm2.so.1 is not a symbolic link
#
# /sbin/ldconfig: /usr/lib/libbrscandec2.so.1 is not a symbolic link
#
# /sbin/ldconfig: /usr/lib/libbrcolm2.so.1 is not a symbolic link
#
# /sbin/ldconfig: /usr/lib/libbrscandec2.so.1 is not a symbolic link
#
#
2017-09-28 18:50:55|install|libsoftokn3|3.32.1-1.1|x86_64||download.opensuse.org-oss|dee1a98383d85ec3ebf70cadaf7bb3f6846b953e|
2017-09-28 23:02:37|command|root@linux-Tower|'zypper' 'dup'|
# 2017-09-28 23:02:42 vivaldi-snapshot-1.13.971.8-1.x86_64.rpm install failed
# rpm output:
On Thu 26 Oct 2017 01:56:02 PM CDT, GooeyGirl wrote:
malcolmlewis;2843115 Wrote:
> Hi
> So, run the history command from a terminal, also while there run;
> >
Code:
> >
> history | less
> history | grep mkdir
> history | grep zypper
>
> ls -la .bash*
>
> >
>
> Not a file there owned by root?
>
> In the history file, did you by chance switch to root user only using
> su or run a sudo command…
>
> Then switch to root user with su - (not sudo) and run the history
> command.
Thank you. More interesting commands! Doing all those, nothing stood out
to me as any kind of smoking gun.
Hi
Also check out the !<some_number_command_ref> it will run the command
again without having to type in some long string
For example;
history |tail -n 5
1044 history
1045 osc collab t --project GNOME:Next
1046 history
1047 osc collab t --project GNOME:Next
1048 history |tail -n 5
!1047
osc collab t --project GNOME:Next
Package | GNOME:Factory | GNOME:Next | Upstream
----------------------+---------------+---------------+--------------
NetworkManager | 1.8.4 | 1.8.4 | 1.9.3
gnome-online-accounts | 3.26.1 | 3.26.1 | 3.27.1 (r)
lasem | 0.4.3 | 0.4.3 (c) | 0.5.0 (c)
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.87-18.29-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Sorry Malcolm, i couldn’t really understand your last post. However, as others had suspected, & as i also suspected following the lack of bad things happening after i renamed both directories several days ago, i decided today to delete them. All seems good.
Actually for the case of the CLI “bash”, I prefer to setup to have the CLI history recall use a subset of “vi” editor commands:
In ‘~/.bashrc’ add the line “set -o vi” – GNU Emacs fans can use “set -o emacs”.
This has the advantage that, I have to actively re-execute the command – using the “!<part of the previous command to be executed> “history” method executes something looking like the command to be re-executed (”!rm" will execute a previous “rmdir” command if that was the last matching command string in the shell’s “history”) without asking any questions – in other words something like: “Shoot first – questions will be dealt with later!” . . .
