Disabling of "wide links" violates "principle of least surprise"

[Alain Knaff]

Hello list,

I'm not sure whether this is the right place to post this, if not please
point me to the exact appropriate list or forum.

Recently, after doing what we thought was a routine update of our 9.04
Ubuntu server (getting security updates and "minor" fixes), we were
surprised that suddenly our read-only netlogon share was no longer working.

During the 2 hours that it took to investigate the problem, hundreds of
our users were stuck without their default drives (which are mapped by
the logon script set in smb.conf)

It turned out that the reason for the problem was that we had symlinks
in our netlogon share, pointing to scripts called by our main script.

Thanks to a "wide links = yes" in the netlogon share definition, these
had been working without a problem for many years.

Apparently, now this _explicit_ statement is being disabled because it
conflicts with the _implicit_ default "unix extensions = yes".

Our config file mentions unix extensions nowhere, and until this
episode, nobody on our site was even aware that such an option exists at
all.

In order to save other sites similar grief, may I suggest the following:
1. always make it so that explicitly specified config settings have
priority over any implicit defaults.
2. or, if above is too complicated to implement, make it so that more
well-known, or older options (that are more likely to be in wide,
wanted, use) have priority over the new and more obscure options.
3. [in order to solve this particular conflict], maybe the exclusion
could be lifted on read-only shares (... as the security problem only
exists if users are actually able to create rogue links...)

What do you think?

Thanks for your support,

Alain