AppImage v3.11 on Linux + Dolphin

Bug Reporting Mount & Sync
#1

Hey guys, congratulations on the v3 release. We made it.

To the point. When using the new AppImage on Linux I noticed a few bugs:

  1. Alert upon creating an empty text file with the Dolphin file manager:

icedrive-unable-to-identify
icedrive-unable-to-identify706×315 25.3 KB

Only after the file was filled with text, it was synced and appeared in the Web app.

  1. Upon moving a file to Trash with Dolphin, I get another alert:

image
Probably, I should’ve just deleted the file permanently instead of moving it to local Trash.

This is pretty platform-specific behaviour, but I hope it helps.
Also, I did not run the AppImage as root, since I know this could break things.

Logs:

System Info:

Manjaro Linux 24
Linux kernel 6.10 (64-bit)

#2

This looks like the atomic writing detection taking place

Say for example you edit a word file, what really happens under the hood is, it creates a temp file with the new data, deletes the old file and renames the temp file

The new app catches all this and tries to just do things “as you see it”

Will look further into things though!

#3

Did the actual file itself make it into the cloud? Perhaps those alerts are not really needed if so as its not a “problem” per se

#4

Did the actual file itself make it into the cloud?

The file was uploaded the the cloud storage only after it was filled with data. 0 KB files aren’t getting uploaded and are visible only locally.

Perhaps those alerts are not really needed if so as its not a “problem” per se

I guess so. Just in case, here’s a bit more logs with -verbose argument in the CLI app:

[06.09.2024 20:02:23.949] [6598] mkdir: path = /.Trash-1000 mode = 448
[06.09.2024 20:02:23.949] [6598] access denied (folder create) - creating a hidden folder "/.Trash-1000"
[06.09.2024 20:02:23.949] [6598] The hidden folder .Trash-1000 will not be created.
[06.09.2024 20:02:23.979] [6660] open: /Temp/123/123322.txt flags: 32768
[06.09.2024 20:02:23.980] [6688] read: "/Temp/123/123322.txt" tmpf: "" offset: 0 bufsize: 4096 fd: 30
[06.09.2024 20:02:23.980] [6688] bytes to read: 4096 bytes read: 4 offset: 0
[06.09.2024 20:02:23.981] [6660] release: "/Temp/123/123322.txt"
[06.09.2024 20:02:23.982] [6688] delete file: /Temp/123/123322.txt
[06.09.2024 20:02:23.982] [6688] removing temp file from DB: 2726189639 filename "123322.txt" crypto "0"
[06.09.2024 20:02:23.985] [6688] deleting item: "/Temp/123/123322.txt" id 2726189639 isFolder: false
[06.09.2024 20:02:24.484] [6593] vrec: delete for "//Temp/123/123322.txt"
[06.09.2024 20:02:24.484] [6593] req: deleting "123322.txt" id "2726189639" isDir: false crypto: false
[06.09.2024 20:02:24.646] [6593] the response is: {"error":false,"message":"Added to Trash"}
[06.09.2024 20:02:24.647] [6593] item deleted: "//Temp/123/123322.txt" 2726189639
[06.09.2024 20:02:24.647] [6593] removing temp file from DB: 2726189639 filename "123322.txt" crypto "0"
[06.09.2024 20:02:24.647] [6593] could not delete tmp file (3): "/home/hunter/.local/share/Icedrive/Tmp/37CCC59B.TMP"

That was for moving to Trash. In CLI, it actually removes according to the sync policy.
When deleting permanently, it still tells:

could not delete tmp file (3): "/home/hunter/.local/share/Icedrive/Tmp/621C7E5D.TMP"

Note that I close the text editor before removing a file.
Probably, above is the file you were explaining:

what really happens under the hood is, it creates a temp file

#5

A little update on v3.21.

The issue is no more. The 0KB text file is made it to the cloud in this version. No allerts appeared.

The GUI alert is still there, but the the file gets removed from the cloud in both local and permanent ways (via Dolphin). Apparently, that’s not a bug.

@JimmyB, this topic can be closed. Thank you for the help.