rox lost Right-Click show/hide thumbnails (Solved)

[mikeslr]

Edit: See my last post, viewtopic.php?p=8780#p8780

Well, before I screw something else up trying to fix it, figured I'd ask.

You know that nice capability rox has when you Right-Click the "Eye" on its taskbar about which its tool-tip says "Right:show/hide thumbnails"? Somewhere during my remastering/fiddling I've made the tool-tip a liar .

Left-click to show/hide hidden files works. But whatever settings I've tried via Right-Click Empty Space>options I can't get rox to show thumbnails. Perhaps I haven't tried the right settings? I don't see anything obvious in /root/.config/rox.sourceforge.net/Rox-Filer/options; but then I'm not sure I'd know what to look for and don't want to change something I shouldn't.

If it matter, I'm running a remastered Bionicpup64 with Kernel: 5.3.4-lxpup64 (x86_64) and starting rox via terminal in pertinent part reports:
ROX-Filer 2.11
Compiled with GTK version 2.24.32
Running with GTK version 2.24.32
-- features set at compile time --
Large File Support... Yes
Binary compatibility... No (apsymbols.h not found)
Extended attribute support... No

[williams2]

What haappens if you right click in rox window, and click Display, Show Thumbnails?
Is that option greyed out?
Can you check/uncheck the Show Thumbnails menu item?

If you right click in a rox window, and click Options, Thumbnails does everything look ok?
Is the Show Image Thumbnails checked?

Does changing the size of the icons do anything?

Is there a /root/.thumbnails dir? Is it writable? Is everything in root/.thumbnails writable?
Are there any image files (.png) in /root/.thumbnails/normal/ ?

[mikeslr]

Hi williams2

Thanks for responding and I'll continue to try to find the cause by pursuing your --or anyone else's-- suggestions. It would be good to know what went wrong. But, the question is now sort-of academic.

I had feared that my screw-up had happened while remastering. But, then I remembered since doing that I've backed up my SaveFile twice and I had a vague recollection of checking rox's functionality before replacing the original Bionicpup64 with the remaster. While both the current and next-previous SaveFile displayed the problem, using an earlier (Sept 1st) SaveFile did not. So, it must be a conflict between rox and something I've since installed or sfs-loaded. That's an easy fix: (a) Boot using last SaveFile & Take Screenshots of current installed/loaded applications shown by PPM Uninstall & SFS-Load (b) boot into Good SaveFile and examine SFS-LOAD and PPM Uninstall and see what's been added since Sept1; (c) add those 1-at-a-time and see which breaks rox. Of course, if the screw-up was some 'adjustment' i made and forgot about, your suggestions rather than the process described in this paragraph is more likely to reveal the cause.

I'll pick this up tomorrow. So, don't stay up waiting for my report.

[williams2]

I seem to remember a bug in ext4, where a file or dir stops working properly.
It behaves like a symlink that has had the file it links to deleted.
That is, it displays the same error message.

I seem to remember that someone had that problem with the rox .thumbnalis dir.
The dir could no be deleted or renamed or files put in the dir.

fsck does not seem to help.

It seems to behave as if the name exists in the virtual file system, but it is not linked to a valid inode.

I thought maybe putting data in the file/dir name might fix it by updating the inode, like this:

Code: Select all

echo xyz > /root/.thumbnails

ext3 does not seem to have the bug.

I was just wondering whether you had this bug.

[mikeslr]

The condition described in your above post wasn't applicable: I wasn't even getting thumbnails in the /usr/share/pixmap folder. I had been until some change about a month ago. Didn't realize that: menus and launchers showed icons and I had had no reason to work with icons,

The last suggestion you made in your first reply "
Is there a /root/.thumbnails dir? Is it writable? Is everything in root/.thumbnails writable?
Are there any image files (.png) in /root/.thumbnails/normal/ ?" revealed the problem.

The "normal" folder was decidedly abnormal: A red triangle. The following happened so quickly that I didn't get a chance to record it and am relying on my flaky memory. I right-clicked the Icon and selected properties or permissions which revealed a permissions problem. Wondering if the problem was specific to the "normal" folder or with its containing ".thumbnails" folder, I right-clicked an empty space in the .thumbnails folder, selected new and tried to create a file named "u". Not only could I create that file, the strange "normal" folder disappeared. I think I then deleted the "u" file and was greeted by a new "normal" normal folder --that is, it displayed the folder icon. Browsing into /usr/share/pixmaps thumbnails were displayed and right-clicking rox's "eye" produced the expected toggle effect. Browsing back into the /.thumbnails/normal folder revealed thumbnails.

I have no idea how the normal folder went crazy. But I've marked this thread "Solved". Hopefully, it will remain that way after a Save and reboot.

[mikeslr]

Well, I spoke too soon.

The 'fix' described above did not survive a Save & reboot. On reboot, /root/.thumbnails/normal was again abnormal. The folder had no permissions. I think I then examined /root/.thumbnails permissions and seeing the absence of 'write' permissions gave them for all and sundry. Creating any file/folder in /.thumbnails temporarily corrects the problem. Once that file/folder is created, it can be deleted --leaving /normal empty--and browsing into /usr/share/pixmaps will generate a "normal" folder in /.thumbnais. That folder only has owner read, write, execute permissions. But even with the above changes the 'fix' does not survive a reboot.

permissions of both .thumbnails & nornal

permissions-both.png (403.35 KiB) Viewed 812 times

Edit: booted using SaveFile without the 'thumbnail' problem. Permissions of /.thumbnail and normal folders are read, write and execute only by Owner. Somewhat curiously, there already was a png-file already in it. While the png had a long name consisting of letters, opening it in viewer revealed that it was the graphic I use as a boot-splash, albeit the boot-splash, itself, is in xpm format.

Comparison revealed that since the condition with thumbnails functioning no changes of SFS and only the following applications have been installed.

permissions of both .thumbnails & nornal

permissions-both.png (403.35 KiB) Viewed 812 times

openssl is not likely to have caused the problem. I had previously 'guessed' that to have been the cause. Uninstalling it changed nothing. Nor is it likely that the Iron pet causes the problem. It's a mere "menu-pet" adding only a desktop, pixmap in their usual locations and abash script in /root/my-applications/bin. I'll see what effect uninstalling the others has.

[williams2]

I think this is a file system bug.
I suspect the bug is in ext4 and not in ext3.
I prefer to use ext3, it is more stable than ext4.

Is your savefile or save folder using ext4?

fsck should fix the file system, but I don't think it will,

I suspect the file names are not linked to a valid inode.

What are the inode numbers for the .thumbnails dir and anything in the dir?

Code: Select all

ls -Ri /root/.thumbnails

Can you rename the bad dirs / files?

[williams2]

What does this do?

Code: Select all

stat /root/.thumbnails
stat /root/.thumbnails/normal
stat /root/.thumbnails/normal/*

[mikeslr]

Hi williams2,

Yes. The bad SaveFile is formatted Linux Ext4. But then so is the good one and probably some of the SaveFiles used with my other Puppies. Sometime back I took to using Linux Ext4 when the SaveFile was to be on a hard-drive. While your 'feeling' may be just a 'hunch', a hunch by someone with extensive experience is better than a guess by someone with, at best, reading-knowledge.

Running the command you suggested produced the following:
root# ls -Ri /root/.thumbnails
/root/.thumbnails:
ls: cannot access '/root/.thumbnails/normal': Input/output error
? normal
ls: cannot open directory '/root/.thumbnails/normal': Input/output error

root# stat /root/.thumbnails
File: /root/.thumbnails
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 13h/19d Inode: 15649 Links: 4
Access: (0766/drwxrw-rw-) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-10-26 11:34:14.558567595 -0400
Modify: 2020-10-26 11:34:14.555234261 -0400
Change: 2020-10-26 11:34:14.565234262 -0400
Birth: -
root# stat /root/.thumbnails/normal
stat: cannot stat '/root/.thumbnails/normal': Input/output error
root# stat /root/.thumbnails/normal/*

My recollection --perhaps faulty-- is that in order to run fsck on a SaveFile it can't be in use at the time: i.e., either boot pfix=ram or be running a different Puppy. But then there was something else I would have to do to select the SaveFile. Can you tell me exactly how?

I also recall that there was a technique for converting Linux Ext4 to Ext3. But the specifics escape me.

I'll persist if you think it important. But remember this problem is academic. It's actually easier for me to boot pfix=ram, create a new SaveFile, this time Linux Ext3, and re-stock it: one of the reasons I keep a record of what's been installed; and a bi-produce of almost never employing auto-install. Packages I've downloaded to install are kept in folders on storage, specific to a Puppy when appropriate.

[williams2]

I do not recommend ext4, it is not as stable as ext3.

You should be able to fix the file system by typing:
(the savefile should be not mounted and not being used
for example, it could be a copy of the savefile.)

Code: Select all

# debugfs -w savefile.4fs
debugfs: clri root/.thumbnails
q

assuming you have a savefile.
Without the -w option debugfs is in read-only mode.

Then fsck the savefile:

Code: Select all

fsck.ext4 -v -f savefile.4fs

Press a if you want to answer yes to all the questions.

This should remove the root/.thumbnails dir and contents of the dir.
Files in .thumbnails should be put in Lost and Found dir.
It should work but I don't know if it will.

Always good to backup the original savefile first.
It might damage the file system, though it shouldn't.

It would probably good to try fixing the file system in case it happens to someone else.
You would know whether it would work or not.

[williams2]

You could boot another Puppy, or pfix=ram and mount the file system that the savefile is on.

You could copy the savefile to to another filename, even if it is being used by your Pup
I create a new adrv.sfs file from my savefile that is in use by my running Puppy.
(actually ram, I'm not using a savefile, I always boot pfix=ram)

[williams2]

converting Linux Ext4 to Ext3

I think that the easiest way to convert an ext4 savefile to ext3 would be

create a new blank ext3 savefile
mount the ext4 savefile and the ext3 savefile
copy the files in the ext4 savefile to the ext3 savefile, like this:

rsync -a /mnt/ext4 /mnt/ext3

assuming the savefiles are mounted on/mnt/ext3 and /mnt/ext4

[mikeslr]

Thanks again, William.

Something to keep me busy tomorrow.

[williams2]

stat: cannot stat '/root/.thumbnails/normal': Input/output error

It might be better to try clearing the /root/.thumbnails/normal inode first
to see if it would work:

clri root/.thumbnails/normal

and if it doesn't then try clearing the root/.thumbnails inode which seems to be ok,
which "should" delete everything in that dir:

clri root/.thumbnails

because, if for example, the .thumbnails inode was invalid and you couldn't clear the inode,
you might have to clear the inode of the parent dir /root, which would erase everything in /root.
It would be good to know if clearing the "normal" dir's inode will work or not.

[mikeslr]

Hi williams2,

See Edit:

I'm not going to pursue this further as I've identified the culprit, and a couple other problems at least one of which should be addressed.

Although PPM Uninstall displayed a long list of applications, of which the ones on this post, viewtopic.php?p=8511#p8511 were the latest and therefore the most likely culprits, my recollection of what I had done on Sept 1st was faulty. I had not remastered. Rather what I had done --after unloading SFSes-- was to convert my then SaveFile to an adrv.sfs, then created a new "blank" SaveFile primarily so that SFSes, including the 32-bit compatibility SFS would load on bootup. I'm pretty sure I used the conversion module in the nicOS-Utility Suite. That's the problem to be addressed else: How to distinguish between applications in the adrv.sfs and those actually, subsequently, installed in the SaveFile/Folder?

With only 7 applications newly installed it just made sense, even while pursuing your suggestions using the problem SaveFile, to boot pfix=ram and create a new Linux Ext3 SaveFile. Having done that I installed the 'new applications'. None of which produced the problem. Then I went about making 'minor' adjustments.

One such adjustment was to set Osmo to open to its Task Pane and have that displayed immediately on bootup. Dropping osmo.desktop into /root/Startup/autostart did noting. So I dragged /usr/bin/osmo into /root/Startup. And /root/thumbnails/normal was broken. Worse, removing the osmo symbolic link did not return thumbnails to its former, working, condition.

Don't know why. But the easiest solution is an analog to the advice given in Smith & Dales' Doctor Vaudeville Sketch:

Patient: It hurts when I do this.
Doctor: Well, don't do this.

So I, again created a new SaveFile and didn't.

Under the circumstances,it didn't seem to make sense to try converting the 'problem' SaveFile to Linux Ext3, nor stocking a new SaveFile with its contents. But, still having the problem SaveFile, I booted using it in order to try the suggestion of your last post with the following result:
root# clri root/.thumbnails/normal
bash: clri: command not found
root# clri root/.thumbnails/
bash: clri: command not found

So, I've added the cryptic "Resolved" to the OP.

Thanks again for your help.

Edit: See here, viewtopic.php?p=8686#p8686

[williams2]

I dragged /usr/bin/osmo into /root/Startup. And /root/thumbnails/normal was broken

Someone else had this problem, which seems to be something wrong with an inode in /root/.thumbnails.
I think it is an ext4 bug.
It's really helpful in trying to fix a bug to be able to replicate the bug. Maybe you have done that.

Code: Select all

root# clri root/.thumbnails/normal
bash: clri: command not found

That's not a bash command.

If you run debugfs (a program to debug a file system)
debugfs is interactive, it waits for you to type a command.
Typing clri in the debugfs program is a command to clear a particular inode,
like this: clri root/.thumbnails
That unlinks the dirname and the inode, effectively erasing that dir.

You can run debugfs and have it execute a command, instead of interactive mode, like this:

Code: Select all

debugfs -R "stat root/.thumbnails" /mnt/home/slackosave.4fs 

which is safe because it is readonly.

You can clear an inode like this:

Code: Select all

debugfs -wR "clri root/.thumbnails" /mnt/home/slackosave.4fs

which does change the file system, so the savefile should not be mounted.

[mikeslr]

Hi again, williams2,

I haven't deleted the 'problem' SaveFile. I'll keep it a while so I can run the routines you suggest. But, as I've indicated resolving the problem isn't critical. And there's other things I'd rather be doing, some of which I really should get to.

It's not just a Linux Ext4 bug. It also occurred under the Linux Ext3 formatted SaveFile. See the third paragraph of my previous post.

I'll probably get to this sooner than later. Turn out not to be just osmo. I thought it was osmo. So did not have AutoStart start Osmo in new Linux Ext3 formatted SaveFile. Again everything worked as expected until I had AutoStart start a different PIM. I can live with not adding applications to AutoStart. But that's not the system I want.

The problem does not appear to be wide-spread. My Bionic64 system may be very different from the norm: Changed Kernel, personal choice of a bunch of applications installed, then converted SaveFile to adrv.sfs, now being used with new SaveFile, the 32-bit compatibility SFS and two other common SFSes.

P.S. As i wrote the above I recalled the difficulty I had getting pwidgets to function on bootup before the creation of a SaveFile. I should have mentioned that several months before converting the SaveFile to an adrv.sfs, I had previously remastered. Wondering if any of that process interfered with how AutoStart relates to the rest of the system, the easiest way to find out was:
Start with a fresh bionic64, create a SaveFile; add Osmo to AutoStart, Save, Reboot, see if there's a problem. There wasn't.




.

[williams2]

Usually, an input/output error is a hardware problem.

But I have seen this before, and it seemed to be a file system bug.

In particular, I have seen /root/.thumbnails not working properly.

Whatever rox and/or osmo is doing, it should not result in file system corruption.

Hardware, like a usb drive that is not working absolutely perfectly could cause file system corruption.
It seemed to me that it was a file system bug, and maybe an ext4 problem.
But I don't have enough information to actually know for sure.

And if fsck can't fix the file system, it makes it a more serious problem.

If you wanted, you could make a copy of your save file, you could delete most of the files in the savefile, fill the savefile with zeros so it would compress to a very small size, and send it to the ext devs.

[mikeslr]

Hi again williams2,

And a BIG Thank you, again. [By the way, pay attention when using the Forum's thank you button. It's a toggle. Not recalling that I had already thanked you for a post I clicked it and the Forum offered to 'unthank' you. But at least this time I was paying attention and didn't. Rather I picked a different post to thank you. Again].

The reason I'm thanking you is for your post here. viewtopic.php?p=8552#p8552. Hence the title of this post. Hopefully such title may help future users with similar problems can find your clear instructions on how to employ fsck.

Before running fsck I booted into a different Puppy and followed your instructions from here, viewtopic.php?p=8651#p8651, sample codes:
debugfs -R "stat root/.thumbnails" /mnt/home/slackosave.4fs
then
debugfs -wR "clri root/.thumbnails" /mnt/home/slackosave.4fs
[ Tip: open a text editor and type (or cut&paste) the command followed by the full-path to and name of file. Then cut&paste into terminal].
Either between running the first and the second of the above --vague recollection of some print-out of a problem suggesting the need for running the second-- or after both were run I booted into the problem Puppy and visually observed /root/.thumbnails to be a red-triangle. Of course, files did not appear as thumbnails and the rox-toggle was still broken. So again I booted into a different Puppy and combining my above tip with your instructions, ran code:
"fsck.ext4 -v -f savefile.4fs

Press a if you want to answer yes to all the questions."
fsck effected a substantial number of changes. Visual examination of my SaveFile showed that the SaveFile had been modified. I have since twice booted into the formerly problematic Puppy, executing a Save just to see what would happen. Osmo displays on bootup and rox's Right-Click toggles thumbnail view on-and-off.

I now editing, with some confidence, the OP to show 'Solved'.