Ticket #4235 (new defect) — at Initial Version
file search with relativ ignore_dir working weird
Reported by: | dextarr | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.8.30 |
Component: | mc-core | Version: | master |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Branch state: | merged | Votes for changeset: |
Description
up-to-date-kde-neon$ mc -V
GNU Midnight Commander 4.8.24
Built with GLib 2.63.3
Using the S-Lang library with terminfo database
With builtin Editor and Aspell support
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, sftpfs, fish
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;
Dear Developers,
I have a problem with the file search (M-?) feature.
Lets assume I have the following directory structure:
/tmp/base1/
/tmp/base1/.secret/
/tmp/base1/.secret/config2
/tmp/base1/.secret/.secret/
/tmp/base1/.secret/.secret/config3
/tmp/base1/config1
I want to search for files named 'config*' using following options:
start at = .
ignore list = .secret
find recursive = on
file name = config*
if I'm standing in /tmp/base1/ the result is ./config1, which is what I expect as anything in .secret (and _relative_ below) would be ignored.
if I'm standing in /tmp/base1/.secret/ there is nothing found :(
I would expect the result would be the ./config2 as the ignore list contains a relative ignore (.secret) and only config3 would still get ignored.
Looks like the search gets ignored just because there exists a path component .secret above(!) where I'm standing at, which I find confusing (wrong?).
Turning off ignore_list is not an option because then I would find ./config2 but also .secret/config3 and potentially any .secret/* */config*
I cound not find an ignore_list/option combination where the ignore gets applied really _below_ where I'm standing at...
Is this the expected behavior?
thanks for checking out (and hopefully fixing)!