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

[Michael Tokarev]

23.11.2022 00:23, ArtMG wrote:
..
>> Attachments:
>> * fruit-disable-useless-size_t-overflow-check.patch
> 
> Thanks for the patch Michael, I compiled and ran and although it got out of the disk size functions this time, it still slipped up with

I pushed this patch to debian samba package now.
The check there (which this patch removes) makes no sense on 64bits
(since the value is capped elsewhere) and is obviously wrong on
32bits, - for some reason it tries to calculate capacity in apples
when dealing with oranges all the way, and when sizes of apples and
oranges are entirely different on this platform, this test obviously
doe not do any good.  Also, this is a very specific issue affecting
only very specific use cases (with MacOS operability on 32bit), so
there should be no big harm done this way to make samba upstream
unhappy (if it were for something more widespread, I'd not push this
change to debian package).

> ../../source3/smbd/service.c:787(make_connection_snum)
> make_connection_snum: canonicalize_connect_path failed for service TimeMachineBackup, path /mnt/HDD/TimeMachine

So this particular issue is gone now.  It might have other issues,
maybe due to size of size_t on 32bit in some other place, maybe due
to disk size limits, maybe something entirely different, but this
particular issue is gone.

> I do appreciate you cutting this patch for this issue, however I feel like I've been down this road before with these issues. Push a fix here, and if a new issue doesn't pop up over there straight away, give it a version or three and it will eventually. Hence my reference to whack-a-mole.

It's not whack-a-mole really.  Whack-a-mole assumes there's just one
mole out there, which shows in different holes. But here, we have
many moles collected over the years of no testing.  You whack one
for good, but another dozen are chewing stuff somewhere else nearby,
ready to meet you.  This issue already whacked two which was in
the same place.

> As Andrew points out, this is somewhat outlying as test-cases go. There are few people wanting to rebuild a 32-bit instance of their backup mechanism for each point revision of a large and actively-developed service like samba.

Well, once it's in debian, 32bit packages are provided automatically,
there's no need to rebuild them ;)

> I see no reason, personally, to push for developer attention when the solution is as simple as 'switch to 64-bit OS', and then even OLD versions in all the repos work just fine. Although I do not have statistics to hand, I feel that we must be far enough along the migration curve on the journey from 32- to 64-bit systems, especially when it comes to a core-yet-commodity infrastructure service like samba, to warrant letting go of legacy.

It is not that simple, but can be viewed like this anyway.
Yes, 32bit world is dying, and the future is 64+bits, this is
not question whatsoever.  However, the question is *when* to
declare the death of 32bit world.  We either declare it dead
and stop building/providing samba on any 32bit platform entirely,
or we do not declare 32bit world dead, and provide a good service
there. What we do have now is neither one nor another, 32bit
world is not dead and samba is being provided for it, but the
quality of it on 32bits is, well, questionable.  So we either
should draw this line or fix bugs.

I dunno if it's good idea to push the change upstream though:
history tells me this is nearly hopeless to perform changes
in samba code even if the changes are small and obvious.. but
this is entirely different story.

> Thanks for your good will and effort, nonetheless.

You're welcome.

Thanks!

/mjt