> Hi,
>
> Manuel@mgmux.ulpgc.es wrote:
>
> : I have been able to build (2.1.79 + redhat 5.0) them doing the
> : following.
>
> And what about the size mismatch between libc5 and libc6's uid_t, gid_t
> and mode_t? If nothing is done the kernel will receive the wrong
> parameters to the mount() call.
>
> smbmount uses the following structure defined in linux/smb_mount.h:
>
> struct smb_mount_data {
> int version;
> uid_t mounted_uid; /* Who may umount() this filesystem? */
>
> uid_t uid;
> gid_t gid;
> mode_t file_mode;
> mode_t dir_mode;
> };
>
> Unless this structure is changed to (for example):
>
> struct smb_mount_data {
> int version;
> __kernel_uid_t mounted_uid;
>
> __kernel_uid_t uid;
> __kernel_gid_t gid;
> __kernel_mode_t file_mode;
> __kernel_mode_t dir_mode;
> };
>
> everything will be screwed up. (there are other places in the kernel include
> files where something similar must be done).
I just tried the above modification to <linux/smb_mount.h>, recompiled
smbmnt, and lo and behold everything now works perfectly.. F@#$@ glibc2..
:P
How about someone update the mount tools and maybe that include file with
#ifdefs for glibc2 so nobody else has to go through that.. :)
Another thought, why is there a smbmount and smbmnt.. it seems rather
pointless as the only command smbmount supports is mount, which just calls
smbmnt.. How about integrating smbmnt with smbmount like it originally was
in 2.0.xx? Is this a feasable idea, I'm sure a quick hack could be
whipped up.
How about the mount tool being able to automatically detect NT, 95, Samba,
Wfw, etc, and being able to enable workarounds automatically. :) That is
a bit much to ask though because we arn't really sure which workarounds
solve which problems yet.
Regards,
Dave..
P.S. I'm very happy this is working now.. /me does multiple backflips