Warpinator resets save location to default ~ without warning

[scotmcp]

Distribution

Mint 21.3

Package version

1.8.3

Frequency

Quite often

Bug description

I am migrating from my windows laptop to my linux mint desktop, so doing a lot of file transfers....a little at a time since big transfers seem to have a tendency to fail.

Anyway, about 2 or 3 times a day I get a message that the files failed to save, and when I check it's because the save directory appears to have reset to the default ~ directory rather than the sub-folder that I assigned.
This is a problem when it happens mid-transfer because warpinator seems to delete partial transfers, a design choice of compromise I realize, but it makes the bug even worse :-)

Steps to reproduce

Keep using warpinator until it happens....I don't have specific steps to reproduce

Expected behavior

Folder should not spontaneously revert to ~

Additional information

No response

[scotmcp]

It just happened again, here it the error message

[mtwebster]

Is this the system version of Warpinator or flatpak?

Please try and reproduce this while running:

warpinator --debug

or, in the case of the flatpak:

flatpak run org.x.Warpinator --debug

[scotmcp]

I'll have to do it later, but here is this for now.

[ghost]

I'm running the system version of Warpinator on a clean install of Linux Mint 21.3 Cinnamon. Running with the --debug flag as mentioned above, I see the following when the issue occurs:

(warpinator-launch.py:34215): dconf-CRITICAL **: 16:53:17.820: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
2024-07-06 16:53:17,821::warpinator: No save location set
2024-07-06 16:53:17,822::warpinator: Could not create default save directory - using '/home/mercury'

In my use case, I use Warpinator to send a backup archive from the PC I use as my main machine to another PC I use as a backup server. When Warpinator is the only application running, it works well; I have only observed this issue when I have other applications running alongside it. It seems like the issue is triggered when another application makes some sort of access to the filesystem - not regular reading and writing, per se, but maybe some kind of check of available volumes perhaps?

Additionally, I am using a RAID 1 array as the target destination for the backup PC, the "receiving" machine on which I have this issue. My main machine (the "sender") has not shown any issues, however it is worth noting that I have left the target as ~/Warpinator on this machine.

I have not tested changing the target to a separate hard disk on my main machine to see if the problem would manifest there as well, but if I do so in the future I will update this post.