[linux-cifs-client] Re: [2.6.27 patch] the scheduled smbfs removal

[Steve French]

Harvey Harrison <harvey.harrison at gmail.com> 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