> Hi John, Hi Karel (and Miklos, CCed) 👋! > On Thu, Aug 01, 2024 at 11:16:30AM GMT, John Rinehart wrote: > > `util-linux` seems to fail to handle a use case that users like me seem to > > be hitting with some frequency. The issue is around > > https://github.com/util-linux/util-linux/blob/86b6684e7a215a0608bd130371bd7b3faae67aca/libmount/src/context.c#L2115-L2121 > > and seems rooted in the fact that `util-linux` operates on `type` where > > type is always of the form <a>.<b> but where <b> is apparently assumed to > > not contain Unicode U+002E (ASCII 2E): '.' ("dotless"). I say it "appears > > to assume" this since the logic which appears to remove the subtype does so > > by using `strrchr`, which addresses only the last period in the `helper` > > string. If the `subtype`, itself, has a U+002E character then this won't > > remove the subtype. > > > > As an example, if `helper` looks like > > `path/name.type./subtype/path/with/a.period` then the modified `helper` > > after `strrchr` will look like `path/name.type./subtype/path/with/a` > > instead of the apparently-intended `path/name.type`. > > the convention for filesystem names is (was): > > <type>[.<subtype>] > > For example, for the "mount" helper, it is: > > /path/mount.<type>[.<subtype>] > > I believe it is acceptable for the "path" to contain dots (or any > other characters). The important thing is the last segment of the path > (e.g. /mount.<type>[.<subtype>]). We should not be concerned with > anything else besides the last segment. > > It is strange to assume that <subtype> can also contain path-like > segments and dots. It seems like someone may want to use <subtype> to > encode additional information ... Thanks for your response! If I can restate/augment my case: `util-linux`'s `mount` implementation will fail to properly delimit `type` from `subtype` if `subtype` contains `.`. `subtype` is expected by `mount.fuse` to be an executable compatible with `fuse`. If the executable isn't reachable from the `$PATH` (which appears to be the case with the `systemd` mount target auto-generated from my fstab) then it should be specified absolutely (although this isn't documented in the man pages for `mount.fuse`). You can understand this logic by taking a look at https://github.com/libfuse/libfuse/blob/beff8a8ebe1b413b4b572b93ddca24aaeb904f7a/util/mount.fuse.c#L295-L296 followed by https://github.com/libfuse/libfuse/blob/beff8a8ebe1b413b4b572b93ddca24aaeb904f7a/util/mount.fuse.c#L432 In the case of my OS's absolute path to the `s3fs` binary (compatible with and called by `mount.fuse`), it contains a `.` (because of the version string described previously) which breaks `util-linux`'s `mount` implementation when it attempts to separate the `type` from the `subtype`. `util-linux` hasn't documented any restrictions on character values contained within `subtype`. So, in consideration of Hyrum's law and in the spirit of being liberal in what's accepted while conservative in what's emitted, I'd kindly ask `util-linux` maintainers to support `.` characters in the `subtype` so that users like me can fearlessly specify absolute paths to FUSE binaries in their subtype. > Miklos (CC:), what is your opinion? Is it correct to assume that <subtype> > is whatever? > > Karel > > > > This crops up for users like me because I use NixOS which is a store-based > > Linux operating system using paths like: > > ``` > > $ readlink -f $(which s3fs) > > > > /nix/store/xwbx0fbg65ml2qjl86p9p2w58kghqn8r-s3fs-fuse-1.94/bin/s3fs > > ``` > > (So, paths like `/nix/store/<hash>-<name>-<version>/bin/<cmd>`). `version` > > is usually a dot-delimited string like `1.23`. > > > > I've generated a patch which seems to ameliorate this behavior. It's > > attached (sorry if attachments are not the way to go with this mailing > > list, specifically, or mailing lists, generally - this is my first time > > submitting a patch to a mailing list). The logic is simple, but it > > basically iterates through all possible substrings according to the number > > of U+002E characters in the `type` string. It's a more generic form of the > > logic already present, but it's a little heavy-handed. Happy with any and > > all changes which preserve the apparently-corrected behavior. > > > > Please let me know if I should make any changes or if a change like this > > won't be accepted for some reason or if I'm misunderstanding the > > problem/solution. > > > > Thank you! > > > > Cf. > > 1. https://discourse.nixos.org/t/how-to-setup-s3fs-mount/6283/5 > > 2. https://github.com/NixOS/nixpkgs/issues/46529#issuecomment-655536831 > > > > -- John Rinehart > > > > -- > Karel Zak <kzak@xxxxxxxxxx> > http://karelzak.blogspot.com >
