Re: [homes] share
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yep, I think I changed the order of that test - because we use use the 'snum' attached to the vuid if possible, so as to avoid expensive lookups. The correct fix would be to fix lp_add_home() not to overwrite things when it finds that the home dir share already exists. (Because all the damage is actually done there - the order that the search is done doesn't matter any more, as the share is added as session setup time). Unfortunately the fix I was about to commit seems to be the opposite of an earlier 'fix' for a related bug. I'll need to stare at this a bit more... Andrew, Changing the order of the lookup without letting everyone know is a really bad thing. This is an incompatible change with 2.2. Since you described the correct fix, please take care of this. cheers, jerry -- Hewlett-Packard- http://www.hp.com SAMBA Team -- http://www.samba.org GnuPG Key http://www.plainjoe.org/gpg_public.asc ISBN 0-672-32269-2 SAMS Teach Yourself Samba in 24 Hours 2ed You can never go home again, Oatman, but I guess you can shop there. --John Cusack - Grosse Point Blank (1997) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE+FHWfIR7qMdg1EfYRAroZAKCmA1zv37Cbz5CkXVzBvEG/yAxrCgCgqoeF 0xfeqyczgN14iM8MEmT8GGs= =U5Gm -END PGP SIGNATURE-
Re: [homes] share
On Fri, 2003-01-03 at 04:23, Gerald (Jerry) Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yep, I think I changed the order of that test - because we use use the 'snum' attached to the vuid if possible, so as to avoid expensive lookups. The correct fix would be to fix lp_add_home() not to overwrite things when it finds that the home dir share already exists. (Because all the damage is actually done there - the order that the search is done doesn't matter any more, as the share is added as session setup time). Unfortunately the fix I was about to commit seems to be the opposite of an earlier 'fix' for a related bug. I'll need to stare at this a bit more... Andrew, Changing the order of the lookup without letting everyone know is a really bad thing. This is an incompatible change with 2.2. Since you described the correct fix, please take care of this. Yep - will do. While yes, that is the 'correct' fix, the implementation in code isn't as straight-forward, particularly if we want changes to a user's 'homedir' to be updated. I'll certainly keep an eye on this one. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: [homes] share
On Fri, 2002-12-06 at 07:39, Richard Sharpe wrote: On Thu, 5 Dec 2002, Patrick Welche wrote: The following used to work with several months old code.. # Share Definitions == [prlw1] comment = Windoze transfer path = /usr/windoze valid users = prlw1 browseable = no writable = yes guest ok = no [homes] comment = Home Directories browseable = no writable = yes Now when I smbclient //localhost/prlw1 I end up in my home directory /home/prlw1 rather than in /usr/windoze, so it seems the [prlw1] share isn't being matched, and as prlw1 is a valid userid it is then matched to [homes]. Any thoughts on how I could debug this? Which version of the code? Sounds like someone changed the order of the test. Previously, it used to check for a share of that name, and if not found, checked for [homes] and then [printers]. Yep, I think I changed the order of that test - because we use use the 'snum' attached to the vuid if possible, so as to avoid expensive lookups. The correct fix would be to fix lp_add_home() not to overwrite things when it finds that the home dir share already exists. (Because all the damage is actually done there - the order that the search is done doesn't matter any more, as the share is added as session setup time). Unfortunately the fix I was about to commit seems to be the opposite of an earlier 'fix' for a related bug. I'll need to stare at this a bit more... Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: [homes] share
On Thu, 5 Dec 2002, Patrick Welche wrote: The following used to work with several months old code.. # Share Definitions == [prlw1] comment = Windoze transfer path = /usr/windoze valid users = prlw1 browseable = no writable = yes guest ok = no [homes] comment = Home Directories browseable = no writable = yes Now when I smbclient //localhost/prlw1 I end up in my home directory /home/prlw1 rather than in /usr/windoze, so it seems the [prlw1] share isn't being matched, and as prlw1 is a valid userid it is then matched to [homes]. Any thoughts on how I could debug this? Which version of the code? Sounds like someone changed the order of the test. Previously, it used to check for a share of that name, and if not found, checked for [homes] and then [printers]. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: [homes] share
On Thu, Dec 05, 2002 at 12:39:02PM -0800, Richard Sharpe wrote: On Thu, 5 Dec 2002, Patrick Welche wrote: ... Now when I smbclient //localhost/prlw1 I end up in my home directory /home/prlw1 rather than in /usr/windoze, so it seems the [prlw1] share isn't being matched, and as prlw1 is a valid userid it is then matched to [homes]. Any thoughts on how I could debug this? Which version of the code? Sounds like someone changed the order of the test. Previously, it used to check for a share of that name, and if not found, checked for [homes] and then [printers]. CVS code from this evening (Dec 5 17:53 GMT) Cheers, Patrick
