On Fri, Sep 02, 2022 at 09:56:57AM +0900, Namjae Jeon wrote:
2022-09-02 6:48 GMT+09:00, Jeremy Allison <jra@xxxxxxxxx>:
On Thu, Sep 01, 2022 at 04:37:21PM -0500, Steve French wrote:
I do like that Namjae et al made the format of the .conf file very similar
to the format of Samba's smb.conf file though. I realize there some
users complain that there are too many smb.conf parameters for Samba,
but he seemed to pick a reasonably subset of them for ksmbd.
Samba is a much larger project with many more smb.conf parameters
but it does reduce confusion making the parameter names similar
where possible e.g. "workgroup", "guest account", (share) path, read only,
etc.
and fortunately the default directories for the two smb.conf files are
different so at least the daemons don't use the same file.
Sure, I think the formats and parameter names being as close
as possible is a great idea to allow users to move between
servers as they wish. But making the files the same name
is not a good idea.
This is the first time I've heard that it is problem that ksmbd's
config filename is same with samba's one. Reading the mail threads, I
don't understand exactly what the real problem is... I thought that
using same smb.conf name make users aware that it was forked from
samba's one. I'm a little surprised, I thought that you will say that
we should use the same name. This seems to contradict your previous
opinion that ksmbd's dos attribute and stream xattr format should be
the same with samba's one. It's not difficult to change config
filename of ksmbd if you agree with it. If we think about adding the
ksmbd integration feature in samba recently, I think it would be
better to use the same name for future.
Well as Tom said, it gets very confusing to have the
same name config file.
The file system attributes etc. certainly should be
the same, to allow a user to swap between the two
servers based on need and not lose any meta-data.
But as the features diverge, trying to keep a common
config will get harder and harder.
Better to take the pain now, rather than try and
postpone for later. It'll hurt *worse* later :-).
