commits
Fixes: https://tangled.sh/@rockorager.dev/lsr/issues/3
It turns out macOS does several things that go against the assumptions currently built into lsr:
1. The `/etc/passwd` file has an extensive comment at the top of the file; several lines starting with `#`.
2. macOS (and apparently [some other operating systems](https://community.unix.com/t/negative-uid-gid-i-can-see-em-but-what-the-hell-do-they-mean/139505)) allow negative `uid`s and `gid`s.
So, the changes here:
1. Allow for comments in `/etc/passwd`; and
2. Use `i33` instead of `u32`, `posix.uid_t` and `posix.gid_t` when parsing and using `uid`s and `gid`s.
Suggested-by: @steeltormentor@mastodon.social
Suggested-by: @steeltormentor@mastodon.social
To prepare for other sort options which require the statx field (ie time
sorting), move the symlink data off of Entry to reduce it's size. This
improves sorting speed due to the Entry struct being smaller in memory.
Symlinks are generally rare so using a hashmap should be ok. This was
tested locally in /usr/bin which has a decent amount of symlinks and no
noticeable performance hit was seen as a result of this approach.
It seems it become stale after Zig deps updates.
Fixes: https://tangled.sh/@rockorager.dev/lsr/issues/2
Update ourio to gain runtime setting of io_uring flags so we can support
more kernel versions
- User smaller struct for sorting
- Break out of stating when we hit the queue size so we can manage our
batch size a little better
It turns out macOS does several things that go against the assumptions currently built into lsr:
1. The `/etc/passwd` file has an extensive comment at the top of the file; several lines starting with `#`.
2. macOS (and apparently [some other operating systems](https://community.unix.com/t/negative-uid-gid-i-can-see-em-but-what-the-hell-do-they-mean/139505)) allow negative `uid`s and `gid`s.
So, the changes here:
1. Allow for comments in `/etc/passwd`; and
2. Use `i33` instead of `u32`, `posix.uid_t` and `posix.gid_t` when parsing and using `uid`s and `gid`s.
To prepare for other sort options which require the statx field (ie time
sorting), move the symlink data off of Entry to reduce it's size. This
improves sorting speed due to the Entry struct being smaller in memory.
Symlinks are generally rare so using a hashmap should be ok. This was
tested locally in /usr/bin which has a decent amount of symlinks and no
noticeable performance hit was seen as a result of this approach.