[Pkg-samba-maint] Bug#974868: samba-vfs-modules: Still causing issues - at least on armv5tel/armel

[ArtMG]

> Please check if 4.16 fixes this. If not, I guess the best course is to
> switch to a 64bit system, since apparently samba is having inherent
> issues on 32bit systems.

I have now reproduced the error on 4.13.13 on 32bit, and confirmed it is *still* an issue with 4.16.7 on 32bit. However when I switch to 64bit OS version, the error does *not* occur, not even in 4.13.13. The TimeMachine client successfully mounts the share and completes multiple backups, and the server smbd logs are clean, with no overflow warnings, and definitely no "Invalid or incomplete multibyte or wide character" errors.

> Can we at least retitle this as "... on 32bi platforms",
> since what you describe suggest that it's not specific
> to 32bits.

I concur, mjt, that the new bug title more accurately describes the issue, now

> I for one don't know what vfs_fruit *is*, to begin with. Just read briefly the
> manpage, -- well, it has quite some things, it seems, most of which is related
> to MacOS.  I don't have a MacOS machine.

So, yes, vfs_fruit (named to indicate something apple-like without TM issues) is a module that extends samba to provide macOS-related features - essentially to serve SMB in the way that a Mac would. That means to test any issues one would indeed need some kind of client Mac hardware or simulator available.

> If Samba is to have long-term 32 bit support someone needs to provide
> an upstream patch to run a docker build in 32 bit, ie a 32 bit
> userspace on 64 bit docker hosts. 

Thank you for the wider upstream, persepctive, Andrew. In this particular case, tests also required a terrabyte of storage on hand so that the volume calculations would overflow. In my domestic one-off tests it was easy to lay my hands on an old external HDD and a Raspberry Pi. However in a larger-team, keeping a virtual setup for regression testing, and including the mac client for testing vfs_fruit features – I can see how that is going to make for much tougher logistics.

I guess the question now, it whether this gets marked as 'won't fix', because it only occurs in these specific circumstances ("fruit:time machine max size" is set) and for 32 bit systems, or whether it needs logging upstream? The upstream development cost is likely to be low for this specific bug, but its the ongoing commitment to testing that could weigh more heavily.

Personally I'm happy to migrate to 64bit and leave all the overflows behind me, but I'll leave it to you higher-level project experts to make the important decision. Thanks for all your work.

ArtMG