Repository navigation
Conversation
…OCATION menu The menu of a disk name in the LOCATION column was built from the name of the share only, so Delete, Copy and Move acted on /mnt/<disk>/<share> for a file or folder at any depth. Confirming "Delete" for a duplicate file on disk2 removed the whole share folder of disk2 (find -delete is recursive). For an exclusive share it was /mnt/<pool>/<share>, in the disk view /mnt/<disk>/<disk> and on the flash drive /boot/flash (paths which do not exist). The menu now gets the path of the row: in a user share the same path on the selected disk or pool (/mnt/user/share/dir/file -> /mnt/disk2/share/dir/file), everywhere else the entry itself. The path is now a file name and not a share name, so it is passed to JavaScript as a JSON string in an escaped HTML attribute (names can contain quotes, backslashes, HTML characters or line breaks).
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Build and pass displayed paths emhttp/plugins/dynamix/include/Browse.php |
my_devs now accepts the displayed path and reads the global $user flag. For user-share listings, it builds a path under /mnt/$dev/; otherwise, it uses the displayed path. It JSON-encodes and HTML-escapes the handler argument. Directory and file listings now pass $name instead of $dev_name. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Suggested reviewers: elibosley
Merge Risk: 
Minimal · up to 38ebc
-
No actionable merge-blocking risk remains; the LOCATION actions use the selected row’s path.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passed-
Full details: Title check
-
Explanation
The title names the main change: the LOCATION action menu now uses the correct row path, which stops Delete, Copy, and Move from acting on the whole share. The summary confirms this change to my_devs in Browse.php, which now receives the displayed path and passes it through JSON encoding and HTML escaping. The title is specific and matches the objectives, which describe the same fix. It is 104 characters, which is longer than ideal but still readable.
-
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 1 functions across 1 files.
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit checks the paths with care,
User shares lead to /mnt/ there.
Other paths keep their displayed shape,
Encoded safely for each menu escape.
The browse list sends the path along,
And hops away to browse its song.
Comment @coderabbitai help to get the list of available commands.
🔧 PR Test Plugin AvailableA test plugin has been generated for this PR that includes the modified files. Version: 📥 Installation Instructions:Install via Unraid Web UI:
Alternative: Direct Download
|
|
Found an already existing PR covering this bugfix: |
Summary
Fixes the Delete / Copy / Move menu of the disk names in the LOCATION column of the File Manager. The menu did not act on the file or folder of its row but on the top-level folder of the share on that disk.
Report: https://product.unraid.net/p/file-manager-delete-from-a-disk-name-in-the-location-column-deletes-the-whole-share-folder-on-that-disk-not-the-selected-file
Problem
When a user share is browsed, a duplicate file is highlighted and lists several disks in the LOCATION column. Clicking a disk name and confirming Delete is the obvious way to remove one copy, but the dialog showed
/mnt/disk2/<share>and the confirmed delete removed the whole share folder of that disk (find <path> -deleteis recursive), not the file.Cause:
my_devs()ininclude/Browse.phpbuilt the path of the menu from the name of the share (/mnt/<disk>/<share>) for every row, at every depth. Other views were wrong as well:/mnt/user/share/sub/mnt/disk2/share/mnt/user/share/sub/dup.txt/mnt/user/ssd/sub/mnt/cache/ssd/mnt/user/ssd/sub/dup.txt/mnt/disk1/share/sub/mnt/disk1/disk1(does not exist)/mnt/disk1/share/sub/dup.txt/boot/config/plugins/boot/flash(does not exist)/boot/config/plugins/a.plgFor an exclusive share every row has exactly one location (the pool), so the delete in that menu removed the whole share.
This bug is present for years, so other similar reports of unexpected deletions (which we were not able to reproduce) could had the same cause.
Fix
The menu gets the path of the row:
/mnt/user,/mnt/user0, exclusive share): the same path on the selected disk or pool, e.g./mnt/user/share/dir/file->/mnt/disk2/share/dir/fileBecause the path is now a file name (it was a share name before), it is passed to the JavaScript function as a JSON string in an escaped HTML attribute. File names can contain quotes, backslashes, HTML characters or line breaks.
Testing
sub/dup.txt,other/keep.txtandunique.txton two array disks and one in an exclusive share. Before: the menu ofdup.txtondisk2hands over/mnt/disk2/dfmtest, and the delete job removed the whole folder. After:/mnt/disk2/dfmtest/sub/dup.txt, and the delete job removes only this file.a<b), backslashes, line breaks and unicode reach the JavaScript function unchanged.Summary by CodeRabbit