Re: fuse mount failure when type contains '.'

Karel Zak <[email protected]>
Newsgroups org.kernel.vger.util-linux
Message-ID <bytzy2l3mhrcxpcmhqqmyxj7jeu6jafbyu7pmkx3ocupii5tue@qeiobojgjess>
 Hi John,

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 ...

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  <[email protected]>
 http://karelzak.blogspot.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.