SharedDirWatcher: include Incoming + category dirs in watch set - #743
Merged
mrjimenez merged 1 commit intoMay 27, 2026
Merged
Conversation
…e-project#741) CSharedDirWatcher::RegisterAllPaths() previously subscribed only the explicit shareddir_list to the wxFileSystemWatcher backend. But CSharedFileList::Reload() treats three sources as shared (around SharedFileList.cpp:370): 1) the global Incoming dir (thePrefs::GetIncomingDir()) 2) each category's Incoming (theApp->glob_prefs->GetCatPath(i), i = 1 .. GetCatCount()-1) 3) the explicit shareddir_list So the auto-rescan introduced in amule-project#591 was missing (1) and (2): * A file dropped into ~/.aMule/Incoming did not trigger the watcher -> the file never appeared in Shared until some unrelated CREATE fired elsewhere in the watched tree and incidentally rescanned. * Same story for any category-specific incoming dir. Reproducer from amule-project#741: echo 123456 > ~/.aMule/Incoming/file_in_Incoming # wait — never auto-shared echo 654321 > ~/.aMule/extra/file_in_extra # (extra is shared) # both files appear in Shared within seconds Completed downloads aren't affected: CPartFile signals the scanner directly when a file transitions to Incoming, so end-of-transfer sharing keeps working. The bug only bites manual / external drops into Incoming, which is exactly the case amule-project#741 walks through. Fix: build the effective watch list by mirroring Reload()'s three sources (Incoming + cat paths + shareddir_list), deduplicating by GetRaw() so a user who happened to also list Incoming as an explicit shared dir doesn't get a duplicate watch registration. The dedup matters on Linux/BSD/Windows (per-dir Add()) and on macOS (FSEvents rejects overlapping AddTree streams; an explicit ancestor + Incoming-as-descendant still gets pruned by the existing covered_by_ancestor logic further down). Reported by @danim7 (amule-project#741).
3 tasks
mrjimenez
pushed a commit
to mrjimenez/amule
that referenced
this pull request
Aug 1, 2026
…oject#743) CMuleNotebook::OnRMButton passed event.GetPosition() to PopupMenu() for the built-in Close/Close-tab menu. On wxGTK the right-click lands on the tab strip, which sits outside the client area PopupMenu() positions against, so the coordinate was offset by the tab-strip height and the menu opened above the tab instead of at the cursor. Drop the explicit position so it opens at the pointer.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #741.
CSharedDirWatcher::RegisterAllPaths()previously subscribed only the explicitshareddir_listto thewxFileSystemWatcherbackend. ButCSharedFileList::Reload()(around SharedFileList.cpp:370) aggregates three sources as effectively shared:thePrefs::GetIncomingDir()— the global Incoming dir.theApp->glob_prefs->GetCatPath(i)for each download category — per-category Incoming dirs.theApp->glob_prefs->shareddir_list— the explicit user-configured shares.So the auto-rescan introduced in #591 was missing (1) and (2):
~/.aMule/Incomingdid not trigger the watcher — the file only appeared in Shared the next time some unrelatedCREATEfired elsewhere in the watched tree and incidentally rescanned.Completed downloads aren't affected, because
CPartFilesignals the scanner directly when a file transitions into Incoming. The bug only bites manual / external drops, which is exactly the case #741's reproducer walks through.Reproducer (from @danim7's report)
Fix
Build the effective watch list by mirroring
Reload()'s three sources (Incoming + cat paths + shareddir_list), deduplicating byGetRaw()so a user who happened to also list Incoming as an explicit shared dir doesn't get a duplicate watch registration. The dedup matters on Linux/BSD/Windows (per-dirAdd()) and on macOS (FSEvents rejects overlappingAddTreestreams; an explicit ancestor + Incoming-as-descendant still gets pruned by the existingcovered_by_ancestorlogic further down).Test plan
Built the patched AppImage on Ubuntu ARM (amule-dev-vm via
packaging/linux/build.sh appimage), drove a clean amuled instance over EC, dropped a file inIncomingDir, polledamulecmd show shared. A/B:IncomingDir, 10s wait6ac974287, master tip)show sharedempty86cd0d8f4, this branch)show sharedreports the new file with its MD4 hash