My setup: I have multiple BT clients running at the same time on the same computer sharing the same files. This is because I want to share the same content to multiple networks. Such as the Internet and the I2P network, some private trackers, and so on. I have multiple I2P routers running, so I have multiple I2PSnark instances running, each connected to different I2P router.

When I download a torrent, I download it by a single BT client, or by multiple clients each to its own separate directory. After a torrent is finished downloading, I de-duplicate the contents. I do it by hard-linking the files to each other, so they don't occupy n times the space on my hard disk. After de-duplication is done, I force re-check each torrent in each client and start seeding. So far so good. With I2PSnark BT client that is. I just started using the tixati BT client and it fails to open files for seeding. Even if it is for read-only access, it complains that the file could not be opened, because some other process is already holding it.

Please open files for read-only in non-excusive way. So the files could be used with other applications (such as other BT clients) at the same time.

The error is: error opening: The process cannot access the file because it is being used by another process. (32)

I2PSnark is the one accessing the files exclusively. Try downloading some archive via torrent, then opening it in an archive manager. It will complain until you stop the client completely, and free the data files from its grip.

It might be that Java does not provide fine-grained interoperability with native file systems, it might be that block reading code needs exclusivity and immutable files to not break some of its buffers and pointers, it might be that no one implemented the non-exclusive reads and handling all the possible errors, or closing the extra files that are not uploaded to anyone.

No, definitely not Java issue. I have single Java I2P router (non-plus) running, with integrated I2PSnark. Additionally, I have two I2PSnark standalone (non-plus) instances running. All three programs on a single computer, all having downloaded the torrents to a 100% completion (seeding only), all the torrent files are hard-linked to each other. I'm on Windows, with Java 24, see below. All three programs happily seeding the same torrents, not complaining at all. I used the procmon tool from SysInternals to verify that Java is opening the files in shared mode (shared for reading and writing, not shared for deleting).Now I can not reproduce this with tixati, will try later.


openjdk version "24" 2025-03-18
OpenJDK Runtime Environment (build 24+36-3646)
OpenJDK 64-Bit Server VM (build 24+36-3646, mixed mode, sharing)

The first reply is totally correct.  This is an obvious issue with I2PSnark.

When reading (ie. checking), Tixati opens files with GENERIC_READ and FILE_SHARE_READ, that's all.  There's no exclusive read access.

Snark always opens every file with GENERIC_READ | GENERIC_WRITE | FILE_SHARE_WRITE | FILE_SHARE_READ.  No matter what it's doing.  It should not have the file open for writing when it's only checking.  And the reason other instances of Snark don't trip up on this is because they use FILE_SHARE_WRITE, which is just a way to paper over their problems.  What a mess.

I2PSnark has always been developed as a tiny torrent client internal to I2P node (mainly to spread the load on version updates). The ability to run that plugin with the web server externally is just a convenient hack, probably rooted in the fact that Snark (its ancient ancestor) was a self-contained bittorrent client in Java, and that the plugin only really needs to talk to the node via I2CP, and is still self-contained. Operation of multiple copies was probably not even in the widest scope of the developers, so what they do in that arrangement might not make any sense.

Given that people working on I2P/I2P+ code can be counted on one hand, users who need new features and use cases should probably start making patches on their own.