LinuxQuestions.org - [SOLVED] Current64: Where does the /.cache file come from?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Current64: Where does the /.cache file come from? (https://www.linuxquestions.org/questions/slackware-14/current64-where-does-the-cache-file-come-from-4175605075/)

@kjhambrick, @chrisretusn:

The /.cache directory will be created at a reboot when it does not exist yet. You might remove that directory and reboot to verify this.

It seems you both rebooted on Apr 9 and when you did so it was the first time after installing/upgrading the "culprit" package(s). In other words: the "culprit" package(s) are not from Apr 9 and later, but from Apr 9 and before. If you remember when you rebooted the last time before Apr 9 the search window would shrink considerably.

For the record: the NetworkManager package was rebuilt on Apr 1. However, as I said in my post #50 any other "systemd" package(s) might be the culprit now.
:D

To clarify.

Quote:

Originally Posted by burdi01 (Post 5843678)

@kjhambrick, @chrisretusn:

The /.cache directory will be created at a reboot when it does not exist yet. You might remove that directory and reboot to verify this.

This is known. I have verified this. The /.cache directory did not exist before the reboot on Apr 9, the date shows this. Removing it, brings it back after a reboot, with the date of the reboot. The directory date does not change over time, stays at creation date.

Quote:

It seems you both rebooted on Apr 9 and when you did so it was the first time after installing/upgrading the "culprit" package(s). In other words: the "culprit" package(s) are not from Apr 9 and later, but from Apr 9 and before. If you remember when you rebooted the last time before Apr 9 the search window would shrink considerably.

Again from my perspective, a known factor, packages upgraded after Apr 9 could not be suspect. Not sure were you got that impression. My list only included Apr 9. I could have included the packages from before that too, my last reboot was April 4 after upgrading ktown and a fairly healthy update of Slackware, so there is a boat load of packages that could be suspect. Though I will exclude ktown as a possible suspect. Included in those packages was NetworkManager-1.10.6-x86_64-2.txz (2018-03-31 6:26). I don't suspect NetworkManager because I rebooted with it turn off, the /.cache directory was created after deleting and rebooting. It's something else I suspect.

It's glib-compile-schemas (which correlates with and #31 in this thread)

Quote:

Originally Posted by burdi01 (Post 5843678)

@kjhambrick, @chrisretusn:

The /.cache directory will be created at a reboot when it does not exist yet. You might remove that directory and reboot to verify this.

For the record: the NetworkManager package was rebuilt on Apr 1. However, as I said in my post #50 any other "systemd" package(s) might be the culprit now.
:D

Quote:

Originally Posted by 55020 (Post 5843720)

It's glib-compile-schemas (which correlates with and #31 in this thread)

Thanks 55020 and burdi01

Code:

$ man glib-compile-schemas



<<SNIP>>

      At runtime, GSettings looks for schemas in the glib-2.0/schemas

      subdirectories of all directories specified in the XDG_DATA_DIRS

      environment variable. The usual location to install schema files is

      /usr/share/glib-2.0/schemas.

<<SNIP>>

Yikes ! Sounds like a Wac-a-Mole game then ...

I wonder if the XDG_* Variables need to be set and exported in /etc/rc.d/rc.M rather than trying to find and fix all the rc.scripts that need them ?

-- kjh

P.S. burdi01 --

I did `upgradepkg glib2` on Apr 8, the day before the reboot that created /.cache/

Code:

# ls -la /var/log/packages/glib2*



-rw-r--r-- 1 root root 45142 Apr  8 05:52 /var/log/packages/glib2-2.56.1-x86_64-1

April Reboots

Code:

# last reboot |grep ' Apr '



reboot  system boot  4.14.34          Fri Apr 13 13:26 - 07:47 (2+18:21)  

reboot  system boot  4.14.33          Thu Apr 12 07:20 - 13:25 (1+06:04)  

reboot  system boot  4.14.33          Mon Apr  9 04:56 - 07:20 (3+02:23)  

reboot  system boot  4.14.32          Wed Apr  4 03:31 - 04:55 (5+01:24)  

reboot  system boot  4.14.32          Mon Apr  2 04:50 - 03:30 (1+22:39)

According to my testing, the creation of the /.cache directory is triggered by this section in rc.M

Code:

if [ -x /usr/bin/update-gdk-pixbuf-loaders ]; then

  echo "Updating gdk-pixbuf.loaders:"

  echo "  /usr/bin/update-gdk-pixbuf-loaders &"

  /usr/bin/update-gdk-pixbuf-loaders > /dev/null 2>&1 &

fi

A temporary fix would be to add a line at the end of the /usr/bin/update-gdk-pixbuf-loaders script to remove the /.cache directory.

Code:

[ -d /.cache ] && rm -rf /.cache

Seems to work here.

Thanks 55020 and allend. Knowing the cause is better than not knowing.

Quote:

Originally Posted by allend (Post 5843765)

According to my testing, the creation of the /.cache directory is triggered by this section in rc.M

Code:

if [ -x /usr/bin/update-gdk-pixbuf-loaders ]; then

  echo "Updating gdk-pixbuf.loaders:"

  echo "  /usr/bin/update-gdk-pixbuf-loaders &"

  /usr/bin/update-gdk-pixbuf-loaders > /dev/null 2>&1 &

fi

Confirmed here too.

Adding HOME=/root to the invocation means it gets created in root's home directory instead, which is still annoying but not as bad as littering in the root directory itself.

Confirmed in my neck of the woods that the cause is /usr/bin/update-gdk-pixbuf-loaders.

Quote:

[ -d /.cache ] && rm -rf /.cache

Sure, but why do we have to do nonsense like this? :)

Is there a way to patch this and submit upstream?