On Tue, Oct 22, 2024 at 04:56:05PM +0200, наб wrote:
>
> ...but now that I look at this there's fuse2fs,
> which is naturally better than some third-party implementation.
>
> The interface is a little different
> (the default is -o rw instead of -s -o ro,allow_other,default_permissions)
> so this can be turned into somehing like
> src:e2fsprogs -> fuseext2 (transitional package) Depends: fuse2fs
> + adding the current fuseext2 interface with a wrapper to
> fuse2fs
> and dropping the transitional package in forky and the wrapper... never?
> in forky? forky+1?
>
> (Or just RM fuseext2 and let users figure this out on their own but
> that seems awfully anti-user.)
>
> The epoch is avoided because e2fsprogs is 1.47.1.
I suppose another, simpler approach might be to have the fuse2fs
package ship the fuse-ext2 wrapper script, and then we can just have
the debian fuse2fs replace/conflits with fuseext2. I'm certainly OK
with doing this if someone wants to send me a patch.
I'll note that e2fsprogs's fuse2fs supports 64-bit filesystems, Posix
ACL's, and has thread supports enabled, in contrast to fuse-ext2 which
does not. Fuse2fs also will handle replaying the journal if the file
system was mounted on Linux as ext3 or ext4, and then wasn't cleanly
unmounted due to a system crash.
BTW, if anyone is interested in working with improving fuse2fs,
contact me. In particular, adding some regression testing facilities
would be a great project for someone who is interested in furher
improving fuse2fs on an upstream basis. :-)
- Ted
