file.find does not implement symlink detection/reporting properly
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 15.7k
- Forks
- 5.6k
- Avg merge
- 2d 44m
- Merged PRs (30d)
- 80
Description
Description of Issue
file.find print=type reports a symlink as a file if the file the symlink points to exists. If the file doesn't exist, then file.find reports that the type is a symlink.
This is not how *nix find works. If an inode is a symlink, it should be reported as one even if the file it points to exists.
Setup
# salt-call file.find /tmp/test print=path,type
local:
|_
- /tmp/test
- d
|_
- /tmp/test/file
- f
|_
- /tmp/test/symlink
- f
# ls -l
total 0
-rw-r--r-- 1 root root 0 Oct 27 14:09 file
lrwxrwxrwx 1 root root 4 Oct 27 14:09 symlink -> file
# rm file
# salt-call file.find /tmp/test print=path,type
local:
|_
- /tmp/test
- d
|_
- /tmp/test/symlink
- l
Steps to Reproduce Issue
See above
Versions Report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
Salt Version:
Salt: 3006.4
Python Version:
Python: 3.10.13 (main, Oct 4 2023, 21:54:22) [GCC 11.2.0]
Dependency Versions:
cffi: 1.14.6
cherrypy: unknown
dateutil: 2.8.1
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.1.2
libgit2: Not Installed
looseversion: 1.0.2
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.2
msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 22.0
pycparser: 2.21
pycrypto: Not Installed
pycryptodome: 3.9.8
pygit2: Not Installed
python-gnupg: 0.4.8
PyYAML: 6.0.1
PyZMQ: 23.2.0
relenv: 0.13.12
smmap: Not Installed
timelib: 0.2.4
Tornado: 4.5.3
ZMQ: 4.3.4
System Versions:
dist: rocky 8.8 Green Obsidian
locale: utf-8
machine: x86_64
release: 4.18.0-477.27.1.el8_8.x86_64
system: Linux
version: Rocky Linux 8.8 Green Obsidian
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 with the file.find entry point and reproduce the reported commands with an existing target and a broken target symlink. Trace how the entry point determines and prints each path's type; done means both symlinks are reported as l regardless of whether their targets exist, with coverage for both cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, operating-systems
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100