MuWire-0.8.13-beta3.AppImage - java.nio.channels.OverlappingFileLockException

[slrslr]

Hello,

I was running MuWire-0.8.13-beta3.AppImage for maybe 2 hours on Debian and it shown an exception java.nio.channels.OverlappingFileLockException full detail is here.

MuWire shows in app the Java 18.0.1

[zlatinb]

If I'm understanding the documentation correctly this could only happen a file was being shared and modified at the same time. Are you sharing any directories where files could be modified by another process (such as a torrent client maybe)?

[slrslr]

Yes, definitely. I am currently downloading to the shared folder. I usually do, using 2 apps including Bittorrent client. I see that the parent shared folder is marked in Muwire for monitoring by OS (Linux Debian, stable release).

[zlatinb]

Ok, it's not a good idea to be downloading directly into a folder that is marked by OS monitoring. I really need to document this into a sharing guide on the site, sorry for not having done that yet.

You have two options a) Turn off OS monitoring for the folder where the torrent client and other app are writing to, and switch only to manual monitoring b) Un-share that folder completely and manually move or copy the files to a monitored folder after they're completely downloaded

I realize neither option is very convenient but for the time being MuWire simply can't handle files being modified after they've been shared. A serious rewrite is needed to fix that and that most likely won't happen soon.

[slrslr]

switch only to manual monitoring

Thanks. Maybe I have enabled shared folder monitoring where it was off by default. Actually may be good to be off by default since there is this exception. Good to be off in case share will be refreshed on each MuWire startup anyway. If on startup is a different "refresh" i see i can setup refresh/sync in shared folder options, in seconds (may be more practical to be in minutes), i will set all my folders to like 24 hours i think - maybe i should leave it to 0 and rely on startup sync/refresh.

[zlatinb]

Unfortunately manual watching is only part of the solution. I need to make some changes to fix the behaviour when an already shared file is modified.

Even then downloading into a shared folder is not going to work well because it may cause the file being downloaded to be re hashed continuously. The best practice is to avoid the issue by downloading yo a different folder and only moving or copying the file after it is complete.

I will make some commits to address this and hopefully write a guide to sharing soon.

[zlatinb]

Hi,

I implemented re-hashing of files if they are in automatically monitored folders and their contents change on disk. Also the exception in the title should no longer make it to the UI.

The side effect of this is that if you have a continuously changing file like a torrent download, MuWire will re-hash it continuously and as a result use up a CPU core. There's no way around that I'm afraid.

Please test if you can build from core, alternatively grab the latest CI build and let me know how it behaves.

Thanks

[slrslr]

Git cloned now (Updating ***..4ebdd147) and built - Gradle. MuWire is not crashing for like one hour (~35 minutes of library loading) even i am downloading to a OS monitored folder using 2 apps (assuming that the folder monitoring begin without delay and no need to restart MuWire after enabling the monitoring option. CPU usage is no problem. So maybe close this..

[zlatinb]

I don't remember exactly when monitoring starts so lets give it a day or two...

[slrslr]

After like 2 days runtime, i do not see any problem with updated MuWire..