We messed up smbc_readdirplus :-(

Puran Chand puran157 at gmail.com
Tue Jan 8 06:51:23 UTC 2019


Hey Jeremy,

I remember us mirroring the file_info struct in libsmbclient.h as
libsmb_file_info so that the public part stays same even when internal
structure changes.
The actual throwing away of data in
'source3/libsmb/cli_smb2_fnum_c.c::parse_finfo_id_both_directory_info' was
there since the beginning hence it never occurred to me to capture that
information (my bad.).

I would suggest to go ahead with smbc_readdirplus2() and doing it right
this time. I can take it up.

Pls let me know your thoughts.

-Puran


On Tue, Jan 8, 2019 at 11:09 AM Andreas Schneider via samba-technical <
samba-technical at lists.samba.org> wrote:

> On Monday, 7 January 2019 23:20:30 CET Jeremy Allison wrote:
> > Hi Puran,
> >
> > I'm looking at Red Hat bug:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1569868
> >
> > and realized we made a mistake in the
> > implementation of smbc_readdirplus().
> >
> > struct libsmb_file_info
> >
> > should have been defined as a *superset*
> > of the stat struct that smbc_stat
> > returns, but currently it is missing
> > the st_ino, st_dev, st_mode and st_blocks
> > fields in order to be a superset of struct stat.
> >
> > We actually *have* this data as returned
> > from the SMB2_FIND_ID_BOTH_DIRECTORY_INFO
> > call when enumerating the directory, but
> > then throw it away when populating the
> > struct libsmb_file_info struct.
> >
> > I think the best way forward is to
> > add a smbc_readdirplus_ex() call that
> > returns a new 'struct libsmb_file_info_ex'
> > struct that includes these extra fields.
> >
> > Comments from other Samba Team members ?
>
> I would name it smbc_readdirplus2(), than you can implement 3 if we still
> do
> something stupid (which I don't expect) but who knows :-)
>
>
>
>


More information about the samba-technical mailing list