Re: [2.6.27 patch] the scheduled smbfs removal - Samba

This is a discussion on Re: [2.6.27 patch] the scheduled smbfs removal - Samba ; Harvey Harrison wrote on 05/19/2008 06:06:10 PM: > On Mon, 2008-05-19 at 18:03 -0500, Steven French wrote: > > FYI - last week at connectathon I added one patch relating to backlevel > > support and mapping of open flags ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: [2.6.27 patch] the scheduled smbfs removal

  1. Re: [2.6.27 patch] the scheduled smbfs removal

    Harvey Harrison wrote on 05/19/2008 06:06:10 PM:

    > On Mon, 2008-05-19 at 18:03 -0500, Steven French wrote:
    > > FYI - last week at connectathon I added one patch relating to backlevel
    > > support and mapping of open flags on legacy smb open calls (although
    > > perhaps some longtime smbfs users would not notice since smbfs did not
    > > have this support either).
    > >
    > > The utimes support for backlevel servers is one obvious thing that I have
    > > not added (but smbfs had some limited support for) but was considring
    > > adding.
    > >

    >
    > Just curious if there was a shortlist somewhere of anything supported in
    > smbfs but not in cifs?
    >
    > Harvey


    A partial list follows - let me know if you are aware of more (or even
    better open bugs in the project bugzilla on samba.org)

    Note that some of the backlevel server support issues aren't handled
    by smbfs either (and are hard due to protocol limitations). Guenter
    Kukkukk had been tracking some of the issues with better backlevel
    support (mostly for OS/2 and Win9x servers) so he might have more
    information, but the obvious holes that come to mind are:

    a) utimes to backlevel (lanman) servers
    b) For some pre-Unicode servers it would help to be able to change the
    code page used when translating readdir responses - so that we can
    convert the server's readdir results from the old DBCS code pages to
    UTF-8.
    c) optionally zeroing pages on the client to work around the few buggy
    old servers which don't zero on expanding file size remotely.
    d) support for ancient dos ("core smb") servers

    There are also a few places where Jeff Layton noticed the cifs code
    would always try the more recent smb command (which fails) and only
    then issue the backlevel SMB command (in a few of the places, it would
    be safe to "remember" the "operation not supported" answer or
    equivalent so we don't have to first try a command which will always
    fail).

    Servers in the
    --
    Thanks,

    Steve


  2. Re: [2.6.27 patch] the scheduled smbfs removal

    On Mon, 2008-05-19 at 19:00 -0500, Steve French wrote:
    > Harvey Harrison wrote on 05/19/2008
    > Note that some of the backlevel server support issues aren't handled
    > by smbfs either (and are hard due to protocol limitations). Guenter
    > Kukkukk had been tracking some of the issues with better backlevel
    > support (mostly for OS/2 and Win9x servers) so he might have more
    > information, but the obvious holes that come to mind are:
    >
    > a) utimes to backlevel (lanman) servers
    > b) For some pre-Unicode servers it would help to be able to change the
    > code page used when translating readdir responses - so that we can
    > convert the server's readdir results from the old DBCS code pages to
    > UTF-8.
    > c) optionally zeroing pages on the client to work around the few buggy
    > old servers which don't zero on expanding file size remotely.
    > d) support for ancient dos ("core smb") servers
    >
    > There are also a few places where Jeff Layton noticed the cifs code
    > would always try the more recent smb command (which fails) and only
    > then issue the backlevel SMB command (in a few of the places, it would
    > be safe to "remember" the "operation not supported" answer or
    > equivalent so we don't have to first try a command which will always
    > fail).


    So it's generally people talking to older (or very old) servers that
    would be affected by this? What options would they have if smbfs were
    removed? Is there an alternative to smbfs that would work? FUSE client?

    (Not affected personally, just curious what the alternatives are where
    cifs won't do it)

    Harvey


  3. Re: [2.6.27 patch] the scheduled smbfs removal

    On Mon, May 19, 2008 at 7:49 PM, Harvey Harrison
    wrote:
    > On Mon, 2008-05-19 at 19:00 -0500, Steve French wrote:
    >> Harvey Harrison wrote on 05/19/2008
    >> Note that some of the backlevel server support issues aren't handled
    >> by smbfs either (and are hard due to protocol limitations). Guenter
    >> Kukkukk had been tracking some of the issues with better backlevel
    >> support (mostly for OS/2 and Win9x servers) so he might have more
    >> information, but the obvious holes that come to mind are:
    >>
    >> a) utimes to backlevel (lanman) servers
    >> b) For some pre-Unicode servers it would help to be able to change the
    >> code page used when translating readdir responses - so that we can
    >> convert the server's readdir results from the old DBCS code pages to
    >> UTF-8.
    >> c) optionally zeroing pages on the client to work around the few buggy
    >> old servers which don't zero on expanding file size remotely.
    >> d) support for ancient dos ("core smb") servers
    >>
    >> There are also a few places where Jeff Layton noticed the cifs code
    >> would always try the more recent smb command (which fails) and only
    >> then issue the backlevel SMB command (in a few of the places, it would
    >> be safe to "remember" the "operation not supported" answer or
    >> equivalent so we don't have to first try a command which will always
    >> fail).

    >
    > So it's generally people talking to older (or very old) servers that
    > would be affected by this? What options would they have if smbfs were
    > removed? Is there an alternative to smbfs that would work? FUSE client?


    They could use smbclient (an ftp like tool in the samba suite), but
    there are no obvious reasons for another file system.

    There are some usability improvements that could be made in mount.cifs
    that might be all that is needed for 99% of the users of these very
    old servers. Currently mounting to old servers such as os/2 and win95
    requires specifying a server "netbios name" (mount option
    "servernetbiosname" is needed since netbiosnames are often different
    than the server's tcp name) and also requires overriding the default
    security settings (since the lanamn mechanism is much weaker than the
    NTLMv2 and Kerberos mechanisms). If we had an easier way of passing
    information back across the mount sys call back to a mount helper this
    would be easier to address (since we could send information on the
    server's offered dialects and security mechanisms back to user space
    so we could prompt the user).

    --
    Thanks,

    Steve


  4. Re: [2.6.27 patch] the scheduled smbfs removal

    Am Dienstag, 20. Mai 2008 schrieb Harvey Harrison:
    > On Mon, 2008-05-19 at 19:00 -0500, Steve French wrote:
    > > Harvey Harrison wrote on 05/19/2008
    > > Note that some of the backlevel server support issues aren't handled
    > > by smbfs either (and are hard due to protocol limitations). Guenter
    > > Kukkukk had been tracking some of the issues with better backlevel
    > > support (mostly for OS/2 and Win9x servers) so he might have more
    > > information, but the obvious holes that come to mind are:
    > >
    > > a) utimes to backlevel (lanman) servers
    > > b) For some pre-Unicode servers it would help to be able to change the
    > > code page used when translating readdir responses - so that we can
    > > convert the server's readdir results from the old DBCS code pages to
    > > UTF-8.
    > > c) optionally zeroing pages on the client to work around the few buggy
    > > old servers which don't zero on expanding file size remotely.
    > > d) support for ancient dos ("core smb") servers
    > >
    > > There are also a few places where Jeff Layton noticed the cifs code
    > > would always try the more recent smb command (which fails) and only
    > > then issue the backlevel SMB command (in a few of the places, it would
    > > be safe to "remember" the "operation not supported" answer or
    > > equivalent so we don't have to first try a command which will always
    > > fail).

    >
    > So it's generally people talking to older (or very old) servers that
    > would be affected by this? What options would they have if smbfs were
    > removed? Is there an alternative to smbfs that would work? FUSE client?
    >
    > (Not affected personally, just curious what the alternatives are where
    > cifs won't do it)
    >
    > Harvey
    >
    >
    >


    dropping smbfs in 2.6.27 will conflict with
    - legacy servers like
    - win9x/me
    - OS/2
    - even todays sold "samba NAS boxes (2.x.x)" (!!!)
    - other old legacy servers like MSDOS/IBMDOS

    Cifs vfs - the successor of smbfs - was _initially_
    designed to only support the "NT LM 0.12" and "POSIX 2"
    SMB/CIFS network dialects - NO legacy support at all.

    I really can't talk about "FUSE client" - the burden
    is on cifs vfs ... to also support legacy servers.

    Steve French has already mentioned "some
    not implemented legacy features".

    What is not working today in cifs vfs (regarding legacy servers):
    - stat()
    - utimes()
    - ....

    There might be more glitches ...

    Cheers, G√ľnter

    Btw - work is done to solve the outstanding problems


+ Reply to Thread