Can not list root directory /
SebastianSchildt opened this issue · comments
It can not list fs root "/"
$ nat /
Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }
but
$ ls /
Applications Library Users bin dev home private tmp var
EFI-Backups System Volumes cores etc opt sbin usr
This is on OS X 10.15
Okay, the root cause is a symlink that points to a non-existing file. nat can not deal with that
"the better ls" lmao. Two rust files, not even on homebrew, one option (-f), can't list "/", written by somoene who probably spent more time on his github about section than his code.
And a big German newspaper made an article about it: https://www.heise.de/news/In-Rust-geschrieben-und-uebersichtlicher-nat-will-ls-ersetzen-4937429.html
While it might technically be true, that this a few thousand lightyears behind ls in.. everything it is also true, the the account that created this has a factor 30 higher activity on Github last year than you....
Going back to-topic, I replaced calls to metadata
with symlink_metadata
, which quit unintuitively does not follow symlinks, and thus doesn't fail when encountering a dangling one.
I think a better solutions is changing this
let entries = fs::read_dir(directory)?
.map(|res| res.map(|e| e.path()))
.collect::<Result<Vec<_>, io::Error>>()?;
to create a Vector containing the pathes/dsiplay strings and all metadata, to get rid of the metadata calls all over the place (I think it only possible by hand, creating a mutable vector and filling it. Then it could also detect what a symlink is, and change the string to "symlinkname->symlinktarget" as in ls. but maybe there is some RUST-fu magician out there how can map the hell out of it, doing it in one go...)
Also I think using the ?
operator after having read the initial directory list is a bad design choice for this tool, because it will make the program fall over whenever stumbling across some unexpected things...
Thanks to @SebastianSchildt symlinks now work. Thread closed.