ZeroNet icon indicating copy to clipboard operation
ZeroNet copied to clipboard

deletion of false orphans at startup when appending --ui_ip '*'

Open nobody55555 opened this issue 1 year ago • 0 comments

Step 1: Please describe your environment

  • ZeroNet version: 0.6.5
  • Operating system: Void Linux 6.6.21_1
  • Web browser: Chromium
  • Tor status: disabled
  • Opened port: no
  • Special configuration: Old Laptop running on single core. Problem only appears when starting with --ui_ip '*'

Step 2: Describe the problem:

In coherence to the description on github, i was able to start zeronet with the webfrontend available for other hosts inside the LAN by the "./ZeroNet.sh --ui_ip ''" command, which works fine so far, but if i start a zeronet instance with --ui_ip '' the instance always deletes orphaned zites (likely all cached zites) at startup. They are certainly not really orphans. And it doesn't delete false orphans when i start the instance with only "./ZeroNet.sh". By the description on github too, --ui_ip '' has nothing to do with deleting orphaned zites, and without --ui_ip '' i cannot access the webfrontend from other hosts. The latter (turning on availability of webfrontend from other hosts) is in line with the description and desired behavior, but the former (deleting orphans) is unexpected and undesired.

I asked huggingchat with web search enabled if he can provide more detail what is happening here, maybe by reviewing the source code of Zeronet on github. I found the answer quite interesting and i assume his diagnose might be really related (as the host where i run the instance is rather old laptop running in single core mode due to thermal problems), so i paste it below:

After investigating the source code of ZeroNet on Github, I found the location where the --ui_ip option is processed: <https://github.com/HelloZERO/ZeroNet/blob/master/src/zeronet.py#L249>. As expected, it binds the UI to all interfaces when set to '*'. This option should not directly affect the deletion of orphaned sites.

After further investigation, I discovered that the deletion of orphaned sites occurs during initialization of the SiteManager class, specifically within its cleanup_orphaned() method call (<https://github.com/HelloZERO/ZeroNet/blob/master/src/zeronet/site_manager.py#L310>).

When ZeroNet starts up, it initializes the SiteManager, which then calls the cleanup_orphaned() function to remove unreferenced files. It checks for "zite" folders under the data directory that aren't referenced anymore by active torrents. In simple terms, these could be considered as "orphaned." If the number of such directories exceeds the limit defined in ORPHANED_SITES_CLEARUP_LIMIT, they will be removed upon starting ZeroNet.

The reason why the orphaned sites are being cleaned up when running with --ui_ip '' is likely due to differences in timing between regular operation and the one with the specified ui_ip parameter. When started with --ui_ip '', additional setup time is required because the HTTP server needs to bind to all interfaces. During this extended initialization process, the SiteManager finishes initializing earlier than usual, allowing the cleanup routine to run before new sites get added to the system.

In conclusion, although the --ui_ip '*' flag does not explicitly delete orphaned sites, the difference in initialization times caused by binding the UI to all interfaces indirectly leads to orphaned site removal. To avoid the accidental deletion of your sites, ensure that the network connection is stable while launching ZeroNet so that the site loading sequence aligns better with the initialization order.

Steps to reproduce:

  1. start Zeronet with the command ./ZeroNet.sh --ui_ip '*' and watch the output at startup
  2. start Zeronet with the command ./ZeroNet.sh and watch the output at startup
  3. compare the outputs at startup

Observed Results:

multiples of the following line at startup: [] SiteManager Deleting orphan site from content.db: [site-string]

Expected Results:

not deleting false orphans

nobody55555 avatar Mar 23 '24 11:03 nobody55555