/root/.usr/share/pixmaps corrupts puppy

[MU]

Puppy 1.0.5

I you create this folder manually or by extracting a .tgz, the loop-device gets broken.

When you reboot, there appear strange numbers when trying to unmount /dev/loop1.

After reboot, window-managers do not work.

If you remove this folder and reboot, everything is ok again.

Mark

[rarsa]

Interesting.

My question is: Why would someone explicitly extract to /root/.usr/... ?

As I've said in a different thread: /root/.usr and /root/.etc are just implementation details that shouldn't be exposed in scripts.

As I see it, scripts and instalations should always write to /usr or /etc.

It is not a good practice to depend on implementation details. When the implementation changes, it will break everything that depends on them.

"Code to the interface" is the best practice even if you know the implementation details.

The abstraction in this case is /usr and /etc are writable, however it was implemented.

[MU]

Yes, but it happens too, when extracting an archive that contains pictures in /usr/share/pixmaps.

This is, how I found the bug.

I posted the example of
mkdir /root/.usr/share/pixmaps to give you a quick way to reproduce the error.

You also may create a dotpup, that extracts files to /usr/share/pixmaps, I deleted the one that caused me my trouble.

Mark

[bombayrockers]

Yes i have also been plagued by this problem. it occurs because
/root/.usr/share/pixmaps is translated as /usr/share/pixmaps which is a sim link to /usr/local/lib/X11/pixmaps when files are extracted upon /usr/share/pixmaps this link gets borken and hence the error

so extract you pixmaps to /root/.usr/local/lib/X11/pixmaps this will work.

[BarryK]

You should never write directly to /root/.usr/, at least not after it is mounted on /usr, as that breaks unionfs. Unless you reboot.

[guest]

sorry i just blatantly cut pasted /root/.usr

rather it should be root/usr/local/lib/X11/pixmaps