Re: [PATCH v3 1/6 incubator] smb: Update to new api

Damien Zammit, le dim. 23 août 2026 23:14:11 +0000, a ecrit:
> On 24/8/26 7:44 am, Samuel Thibault wrote:
> > Damien Zammit, le mer. 12 août 2026 00:57:07 +0000, a ecrit:
> >> Convert all the legacy api calls to modern ones.
> >>
> >> Requires to remove _FILE_OFFSET_BITS and be compatible with samba.
> >>
> >> If samba is compiled on a 32b machine, it may only support 32 bit offsets.
> > Mmm, have you tried building this on a 32b machine? Which version of
> > libsmbclient-dev were you using? With 2:4.24.6+dfsg-1, I am getting:
> >
> >
> > /usr/include/samba-4.0/libsmbclient.h:84:13: error: size of array ‘smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS’ is too large
> >     84 | typedef int smbc_off_t_should_be_at_least_64bits_use_LFS_CFLAGS[sizeof(off_t)-7];
> >        |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> I did not test this on 32b.  I tried to infer what to do from the code 
> and bug reports.
> 
> Maybe smb supports 64 bit offsets after all on 32b?
> [...] but that compile time error looks like it is giving the answer(?)

It looks so, yes, since it requires applications including
libsmbclient.h to get a 64b off_t.

This is explained in ./debian/patches/libsmbclient-ensure-lfs-221618.patch 

“
We build samba with LFS (Large File Support) even on 32bits.
This means some types like off_t are 64-bit wide, again,
even on a 32bit host.  libsmbclient.h uses off_t in function
prototypes, and thes prototypes muct match those which were
used at samba compile time - if some other source includes
libsmbclient.h without LFS, it'll get wrong prototypes and
the resulting binary will most likely crash when using
libsmbclient functions.

Detect and error-out this at compile time.

We can not do anything with this in the public header since
it is alredy too late to redefine things, since we can't
guarantee we're the first header a program #includes, and
at the time this libsmbclient.h is included, off_t can
already be defined so our (re)define of _FILE_OFFSET_BITS
does nothing already.

Patching libsmbclient.h to use off64_t means client program
should change their off_t to off64_t too when storing
file offsets returning from libsmbclient, so this is not
an option too.

With this change, we will error out even if the user source
does not use any off_t-related functions. Namely, it was ok
to #include <libsmbclient.h> and use smbc_open/smbc_read/
smbc_write/smbc_close without _F_O_B=64, - neither of these
functions uses off_t. smbc_lseek and others doesn't work,
but if a program does not use them anyway, whole thing will
just work even without enabling LFS.  Ideally we can probably
check each individual function which is being affected, by
replacing it with #error if sizeof(off_t) < 8.  But this
requires quite some hackery...
”

which is a debian-specific change.

I.e. we probably want to add a debian-specific patch to util-hurd to set
64b access, while leaving the upstream smbfs source without it, so that
distributions which do not compile samba with 64b off_t can build smbfs
correctly.

And, yes, untested software is broken software, as Donald Knuth says

“
Beware of bugs in the above code; I have only proved it correct, not
tried it.
”

Samuel