Does not cleanup after itself (Debian Linux)

[jjgmcmaster]

I uninstalled it a while back, but it left network connections files, *.nmconnect (/etc/NetworkManager/system-connections/). Can be exceedingly problematic. It needs to properly cleanup after itself properly. I suggest it provide a removal trigger for uninstallation. (For portability re AppImage, perhaps a built-in removal/cleanup parameter, say "--purge" or whatever, as most users simply delete AppImages. Make sure to document this on the first run.)

[spieglt]

It should delete the saved network connections after each transfer, but I have noticed occasions where this doesn't happen, especially when Linux is hosting the wifi network. I use Tauri's build command to make the AppImage and am not sure if there's a way for me to insert custom triggers or commands there, but in any case the goal would be to fix the bugs that are preventing the connections from being deleted post-transfer, whether via cancellation, error, or normal completion. What do you mean specifically by "exceedingly problematic"?

[jjgmcmaster]

I may have overstated it there with "exceedingly", but essentially, the network manager will connect to that network almost every time the primary network is down, unless the connection files are removed. It could become a big nuisance if the wireless router often goes. Especially if the user is only glancing at the tray icon and either isn't in front of their machine when the notification pops up or is simply too busy working to notice. Or, obviously if their system uses a very bare-bones DE of their own design sans notifications. It could be frustrating for new users of any DE, though, as this connection becomes the default once it gets fallen back on. I will say there that this is also an inherent problem with Network Manager, as it doesn't retain pins, and it doesn't remove connection files when removing a connection either.
As for triggers, I don't think there's any way to achieve this because AppImages exist in their own "space" and and therefore, uninstalling them is basically deleting them. So my only solution for that is to provide something like a --purge switch to invoke FC with before deletion and provide tla startup notice on the first run saying to run FC with --purge before removing it...
All that obviously becomes redundant if FC clean up on closing, but also does checks on opening to see if last cleanup was successful, and report accordingly.

[spieglt]

Hi, do you remember which OS you were transferring to/from besides Linux? Trying to figure out if this is a problem when Linux is hosting the hotspot or joining.

[spieglt]

Never mind, I found the problem.

[spieglt]

Wrote what I think is a complete fix, will test and release soon.

[spieglt]

I should say, I think I've fixed the issue of nmcli connection delete being called properly. I haven't done anything specifically about the contents of /etc/NetworkManager/system-connections/, but on my Mint 21 system, using nmcli deletes the .nmconnection file from that folder.

[spieglt]

I'm actually going to wait to release this until I've implemented the folder mirroring mode discussed in #53 as version 8.0. I hope to get that done relatively soon so no point in making two separate releases.

[spieglt]

Took longer than expected but version 8 is out. It should fix this issue. Please let me know either way if you try it.

[neitsab]

Hi, I came to report the same issue happened for me with version 8.0.1-1 on Arch Linux, installed with the AUR package flying-carpet-bin.

Two connections were left over after using FlyingCarpet, with one systematically taking over regular Wifi and activating when I reboot my laptop. This connection had been used to transfer files from an iPhone, I had quite some issues and so not all transfers exited cleanly.

Let me know if I can provide more troubleshooting info, and otherwise thank you for this program which enabled file sharing when everything else had failed 😊

[Artim96]

I'm seeing this issue to, testing on Debian Testing, installed from the linux_flying-carpet_8.0.1_amd64.deb and just tested against Android. What I've noticed is that it didn't matter if Debian was the sender or the receiver. But it seems to be succeeding more often than not.

I'm attaching some journal warnings and errors happening around the last failure I was able to record. I also tried recording an strace log, but sadly the last time this behavior showed it didn't write the log to the file and it has succeeded since, so maybe I can upload that at a later time if it would help.

fc_journal.txt