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
chryxc wrote: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)
qarmin wrote:It save files into current path
If app works, when current dir is:
It will try to write files into
so changing current folder will change location where files are written.
From CLI changing this is quite simple
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
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.
