RFC: 1.7.33 problem with user's home directory
Thu Nov 13 09:27:00 GMT 2014
On Nov 12 09:45, Warren Young wrote:
> On Nov 11, 2014, at 3:18 AM, Corinna Vinschen <firstname.lastname@example.org> wrote:
> > 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%).
> > 2. If homeDirectory is empty, fall back to /home/$USER.
> This is just a subset of what I suggested, so I’m in favor of it.
> (By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.)
This would be most easily implemented as well.
The beauty here is that probably 99% of the home users don't set
HOMEDRIVE/HOMEPATH in their SAM. So they get /home/$USER as fallback,
which is what they got with /etc/passwd as well. And SAM users have the
XML-like description field entry as well.
For AD environments HOMEDRIVE/HOMEPATH are typically set, though.
Here the users get what they have to use as homedir anyway.
It's simple, but it should work OOTB for most people.
> > 1. Always use /home/$USER and let the admins come up with a matching
> > mount point scheme.
> That’s neglecting your responsibility as BDFL to set a sensible
Heh. I didn't see myself as BDFL yet. Not sure if that's an honor.
> default. The consequence is that everyone will do it differently, and
> then you’ll have to support everything on an equal basis, because you
> chose not to endorse anything.
> When you choose a sensible default, you get the option to criticize
> and even deprecate wild alternative schemes.
This is a philosophical argument. You'd have to argue in how far
always using /home/$USER is NOT a sensible default.
> > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
> > the above:
> > home: [unix|win|home]...
> > - "unix" means, set pw_dir to unixHomeDirectory
> > - "win" means, set pw_dir to homeDirectory
> > - "home" means, set pw_dir to /home/$USER
> > - Multiple entries are possible.
> > - Default in the absence of this setting is: always set pw_dir to
> > /home/$USER.
> I see that as orthogonal. It has the advantage of providing not only
> a sensible default but also a list of endorsed alternatives.
> Whether you *want* to endorse some or all of these alternatives by
> codifying them is a separate question.
I guess I end up doing this anyway. How complex it becomes is another
question, which I can answer probably only after starting to code it.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin