[BUG] cp.list_master does not properly respect prefix
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 15.7k
- Forks
- 5.6k
- Avg merge
- 2d 44m
- Merged PRs (30d)
- 80
Description
Description
Given a SaltFS tree that looks like this (assuming e.g. /demo/...):
demo/
├── a
│ ├── b
│ │ ├── c
│ │ │ ├── targetfile1
│ │ │ └── targetfile2
│ │ ├── c_file
│ │ └── c_file2
│ └── b_file
└── a_file
4 directories, 6 files
Calling cp.list_master with prefix=demo/a/b/c OR with prefix=demo/a/b/c/ always results in the following:
demo/a/b/c_file2
demo/a/b/c_file
demo/a/b/c/targetfile2
demo/a/b/c/targetfile1
instead of at least one of the above (preferably for the fix, the one with the trailing slash -- which I presume is being trimmed off before evaluation/comparison) returning the following:
demo/a/b/c/targetfile2
demo/a/b/c/targetfile1
Setup
See above.
- on-prem machine
- VM (Virtualbox, KVM, etc. please specify)
- VM running on a cloud service, please be explicit and add details
- container (Kubernetes, Docker, containerd, etc. please specify)
- or a combination, please be explicit
- jails if it is FreeBSD
- classic packaging
- onedir packaging
- used bootstrap to install
Steps to Reproduce the behavior
See above. This behavior occurs both when invoked in a template (e.g. {% filelist = salt['cp.list_master'](prefix='<...>') %}) and when invoked directly (e.g. salt 'minion*' cp.list_master prefix='<...>').
Expected behavior
See above; a prefix especially with a trailing slash should match only children of that path, not children and siblings as if the slash was not specified.
Screenshots
N/A; see above.
Versions Report
salt --versions-report
master:
Salt Version:
Salt: 3007.1
Python Version:
Python: 3.10.14 (main, Apr 3 2024, 21:30:09) [GCC 11.2.0]
Dependency Versions:
cffi: 1.16.0
cherrypy: unknown
dateutil: 2.8.2
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.1.4
libgit2: 1.8.1
looseversion: 1.3.0
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.7
msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 23.1
pycparser: 2.21
pycrypto: Not Installed
pycryptodome: 3.19.1
pygit2: 1.15.0
python-gnupg: 0.5.2
PyYAML: 6.0.1
PyZMQ: 25.1.2
relenv: 0.16.0
smmap: Not Installed
timelib: 0.3.0
Tornado: 6.3.3
ZMQ: 4.3.4
Salt Package Information:
Package Type: onedir
System Versions:
dist: almalinux 9.5 Teal Serval
locale: utf-8
machine: x86_64
release: 5.14.0-503.26.1.el9_5.x86_64
system: Linux
version: AlmaLinux 9.5 Teal Serval
minion:
Salt Version:
Salt: 3007.1
Python Version:
Python: 3.10.14 (main, Apr 3 2024, 21:30:09) [GCC 11.2.0]
Dependency Versions:
cffi: 1.16.0
cherrypy: 18.8.0
dateutil: 2.8.2
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.1.4
libgit2: Not Installed
looseversion: 1.3.0
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.7
msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 23.1
pycparser: 2.21
pycrypto: Not Installed
pycryptodome: 3.19.1
pygit2: Not Installed
python-gnupg: 0.5.2
PyYAML: 6.0.1
PyZMQ: 25.1.2
relenv: 0.16.0
smmap: Not Installed
timelib: 0.3.0
Tornado: 6.3.3
ZMQ: 4.3.4
Salt Package Information:
Package Type: onedir
System Versions:
dist: almalinux 9.5 Teal Serval
locale: utf-8
machine: x86_64
release: 5.14.0-503.21.1.el9_5.x86_64
system: Linux
version: AlmaLinux 9.5 Teal Serval
Additional context
N/A
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the cp.list_master entry point and reproduce the supplied SaltFS tree with prefixes both with and without a trailing slash. Verify the behavior against the expected output: a trailing-slash prefix should return only targetfile1 and targetfile2, while excluding c_file and c_file2.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100