Howto: Popular AppImages one click away

[M. Eerie]

It seems the Ungoogled-Chromium AppImage has changed it's repo...

This is the new URL to the latest AppImage build.

[Rava]

It seems the Ungoogled-Chromium AppImage has changed it's repo...

This is the new URL to the latest AppImage build.

Thanks for the heads up.

This ungoogled-chromium_119.0.6045.105-1.1_linux.tar.xz on the same page as your link above is the binary package, not the source code I presume?

[M. Eerie]

I believe the source code should be any of the files named Source Code (zip/tar.gz) just below the one you indicate.

[Rava]

I believe the source code should be any of the files named Source Code (zip/tar.gz) just below the one you indicate.

That's how I understand it as well, so the ungoogled-chromium_119.0.6045.105-1.1_linux.tar.xz would be a binary package (useful when one wants to create a module; maybe even

Code: Select all

update-browser -c

uses that file?)

[Rava]

Lossless Cut V3.58.0 available.
I recommend renaming the AppImage when Downloading, e.g. like so:

Code: Select all

wget -c https://github.com/mifi/lossless-cut/releases/latest/download/LosslessCut-linux-x86_64.AppImage -O LosslessCut-linux-x86_64-3.58.0.AppImage
chmod a+rx LosslessCut-linux-x86_64-3.58.0.AppImage

You see which version /releases/latest/download/LosslessCut-linux-x86_64.AppImage it is by going to https://github.com/mifi/lossless-cut/releases
(When you use my above code after many weeks and after a new version already got released, then the name would not be accurate)

161365605 bytes, 153.89 MB, md5sum 9f8a3cbbaa8acc801da8c12adb40c425

At least on my Porteus 5.01 Xfce 4.16 system the V3.58.0 loads much faster than the last one I downloaded and used, V3.56.0.

[babam]

Czkawka - Multi functional app to find duplicates, empty folders, similar images etc.


GTK3 ---> https://github.com/qarmin/czkawka/releases/tag/4.1.0
https://github.com/qarmin/czkawka/releases

[Rava]

Czkawka - Multi functional app to find duplicates, empty folders, similar images etc.
https://user-images.githubusercontent.c ... bbd2bf.gif
https://github.com/qarmin/czkawka/releases

Could it be that the smaller AppImage https://github.com/qarmin/czkawka/relea ... i.AppImage (6.28 MB) lacks some files?
I downloaded it and when starting it all I get is this: (I renamed it to reflect its version)

Code: Select all

guest@rava:/tmp$ ./linux_czkawka_guiV6.1.0.AppImage 
czkawka_gui: error while loading shared libraries: libgraphene-1.0.so.0: cannot open shared object file: No such file or directory

Added in 7 minutes 27 seconds:
I lso had to make all these modules and activate them:

Code: Select all

lib64graphene1.0_0-1.10.8-1.mga9.x86_64.xzm
lib64gtk4_1-4.12.2-1.mga10.x86_64.xzm
lib64tiff6-4.6.0-1.mga10.x86_64.xzm
lib64tracker3.0_0-3.6.0-1.mga10.x86_64.xzm

but ./linux_czkawka_guiV6.1.0.AppImage would still come up with an error, so now I download the huge AppImage. .(

Added in 3 minutes 39 seconds:
But even the 38 MB AppImage would not load (I renamed it to reflect its version):

Code: Select all

guest@rava:/tmp$ ./linux_czkawka_gui_alternativeV6.1.0.AppImage
/tmp/.mount_linux_r9DVFv/AppRun.wrapped: error while loading shared libraries: libthai.so.0: cannot open shared object file: No such file or directory

@babam: how did you manage to get it to run?

[babam]

@Rava, Use the old version (gtk3) https://github.com/qarmin/czkawka/releases/tag/4.1.0

[rych]

Use the old version (gtk3) https://github.com/qarmin/czkawka/releases/tag/4.1.0

Yes, that works and a small size too. As for the newer releases, Rava, we discussed it in 80+ modules available (Post by ncmprhnsbl #93831) -- I couldn't make it work in the end. Rarely used so the gtk3 version suffices as it works out-of-the-box

[Rava]

@Rava, Use the old version (gtk3) https://github.com/qarmin/czkawka/releases/tag/4.1.0

For that version, the sizes of linux_czkawka_gui.AppImage and linux_czkawka_gui_alternative.AppImage are switched:
https://github.com/qarmin/czkawka/releases/tag/4.1.0

Code: Select all

linux_czkawka_gui.AppImage               34.1 MB   2022-04-24T06:20:49Z
linux_czkawka_gui_alternative.AppImage   3.76 MB   2022-04-24T06:21:18Z

compared to https://github.com/qarmin/czkawka/releases/tag/6.1.0

Code: Select all

linux_czkawka_gui.AppImage               6.28 MB   2023-10-15T08:20:22Z
linux_czkawka_gui_alternative.AppImage   38.3 MB   2023-10-15T08:20:33Z

Anyone knows why that is?
Does the 4.1.0 linux_czkawka_gui_alternative.AppImage 3.76 MB work for you?

Added in 10 minutes 8 seconds:
Did as guest a

Code: Select all

guest@rava:/mytmp/czkawka$ wget https://github.com/qarmin/czkawka/releases/download/4.1.0/linux_czkawka_gui_alternative.AppImage -O linux_czkawka_gui_alternativeV4.1.0.AppImage
[skipping wget output]
guest@rava:/mytmp/czkawka$ chmod a+x linux_czkawka_gui_alternativeV4.1.0.AppImage
guest@rava:/mytmp/czkawka$ ./linux_czkawka_gui_alternativeV4.1.0.AppImage 

and it works out of the box.

Added in 7 minutes 49 seconds:
It has as default search path this:

Code: Select all

/tmp/.mount_linux_L1DP7y/usr

I presume that is its mounted AppImage contents whatever-you-call-it folder.
Does that temp-folder (most likely with a different temp name) appear as your default search folder as well?
When executing manually /tmp/.mount_linux_L1DP7y/usr/bin/czkawka_gui like so:

Code: Select all

guest@rava:~$ /tmp/.mount_linux_L1DP7y/usr/bin/czkawka_gui .
guest@rava:~$ 

it has /home/guest as default search path.
What sense makes searching its read-only-tmp-folder for duplicates?

Code: Select all

guest@rava:~$ touch /tmp/.mount_linux_L1DP7y/usr/dummy
touch: cannot touch '/tmp/.mount_linux_L1DP7y/usr/dummy': Read-only file system
guest@rava:~$ 

[Rava]

But more importantly, I used it to search for duplicates, and searching more than 10 GB of files took a while (no surprise there) but unfortunately, it seems not be able to create stable relative symlinks. I explain why that matters.

Let's say the current searched folder is mounted at /mnt/sdb1 and searched was this folder: /mnt/sdb1/folder1/folder2
and one of the found duplicates are these:

Code: Select all

/mnt/sdb1/folder1/folder2/folder3/file1.ext
/mnt/sdb1/folder1/folder2/folder4/file2blabla.ext

It have not tested it but I am sure it would create symlinks from /mnt/sdb1/folder1/folder2/folder4/file2blabla.ext to /mnt/sdb1/folder1/folder2/folder3/file1.ext - and when next time that very /mnt/sdb1/ would be mounted as sdc1 or sdd1 - all symlinks would be broken.

Stable relative symlinks instead would be like so:

Code: Select all

rm /mnt/sdb1/folder1/folder2/folder4/file2blabla.ext # delete 1st duplicate
cd /mnt/sdb1/folder1/folder2/folder4/ # move into folder of 1st duplicate
ln -sf ../folder3/file1.ext file2blabla.ext # create stable relative symlink

and by doing it like so, it would not matter where that partition got mounted: file2blabla.ext would always be a working symlink.

And why I have not yet tested if it would create absolute but breakable or relative and stable symlinks is: I dunno where it saves its results:

Asking it to save the search results it prints this:

Code: Select all

Saved results to file ⁨results_duplicates.txt⁩

but where is that results_duplicates.txt⁩ file?
I looked into /home/guest and not found it there (I started the AppImage as user guest).
I also looked into /tmp - not there as well.
I also looked into the searched folder, and results_duplicates.txt⁩ is not there, either.

Why not tell the user the full path of results_duplicates.txt⁩ - especially since it could be the file was saves onto a RAM disk and will be lost during reboot.

Code: Select all

guest@rava:~$ find . -name ⁨⁨results_duplicates.txt
guest@rava:~$

Code: Select all

root@rava:/tmp# find /tmp/ -name ⁨results_duplicates.txt 2>/dev/null
root@rava:/tmp# 

(2>/dev/null to hide find: ‘/tmp/.mount_linux_L1DP7y’: Permission denied error message)
And using

Code: Select all

find PATH -name "*results_duplicates.txt*"

also gives no results.
Could it be it tried saving the result file results_duplicates.txt into /tmp/.mount_linux_L1DP7y/usr/ ? (which is still a read-only-file system, see my above post)

@rych & @babam
Do you know where ./linux_czkawka_gui_alternativeV4.1.0.AppImage saves such results_duplicates.txt files?

Added in 29 minutes 49 seconds:
https://github.com/qarmin/czkawka/issues/1000

With the latest update to version 6.1.0 I get the following error when trying to save the results: Failed to save results to file Read-only file system (os error 30)

It save files into current path

If app works, when current dir is:

Code: Select all

/home/user

It will try to write files into

Code: Select all

/home/user/dupliactes*.txt

so changing current folder will change location where files are written.

From CLI changing this is quite simple

Code: Select all

cd /any/folder;
czkawka_gui

this will save results into /any/folder

Added in 4 minutes 22 seconds:
Unfortunately, the above is not true for the linux_czkawka_gui_alternativeV4.1.0.AppImage :
I started the AppImage via moving into its base folder

Code: Select all

cd /what/ever

and executing it like so:

Code: Select all

./linux_czkawka_gui_alternativeV4.1.0.AppImage

and its base folder /what/ever/ is writeable for user guest.

Added in 41 seconds:


Added in 5 minutes 46 seconds:
My conclusion for now:
The AppImage is coded to "think" its current folder is /tmp/.mount_linux_L1DP7y/usr/ (as seen this is its default search path) but unlike V6.1.0 the V4.1.0 not displays the "Failed to save results to file Read-only file system" error message.

[Rava]

My conclusion for now:
The AppImage is coded to "think" its current folder is /tmp/.mount_linux_L1DP7y/usr/ (as seen this is its default search path) but unlike V6.1.0 the V4.1.0 not displays the "Failed to save results to file Read-only file system" error message.

If that bug would be squashed in an upcoming update, it would be possible to create a patched version of V4.1.0, but most likely no one would create such a version since most people want the newest available version (regardless it it brings them any real advantages - but will most likely strain your system with much larger dependency load [see my failed attempt in using the newest AppImage version])

If you want to use the V4.1.0 AppImage and really want / need to save its report the quoted post on https://github.com/qarmin/czkawka/issues/1000 states in one reply by giving it a starting work directory it will save such reports in that directory intead of its read-only /tmp/.mount_linux_?????/ path.

I have rebooted since the above issues, so the results from back then are lost anyway. I try getting the V4.1.0 AppImage to write its report elsewhere but its /tmp/.mount_linux_?????/ read-only-path :
first I will make a search in a much smaller folder to just test if it writes its report accurately) and report back here how that went.

And I also not tested if it will create stable symlinks (as described above), but I doubt it will since you must have a routine of using ../path2/file2 or even ../../path2/file2 or even ../../../path2/file2 to get a stable symlink.
And when the two files are not on the same file system (e.g. because one or more of its folders is/are a symlink(s) to a different partition) then even such stable symlinks would also be stable no more.

In Arnie's voice: I'll be back.