On Tue, 19 Apr 2005 20:44:24 -0500 "Jeremy Allison" <[EMAIL PROTECTED]> wrote:
> This is actually a separate (non-ACL) issue. It's not a bug in > the ACL code. I reproduced it last night and am preparing a > response - the problem is the DOS attributes code sees it as > read-only. Do a attrib <filename> command from a Windows client > and you'll see +r at the attribute. It's not strictly a Samba > bug, more a design issue. > I agree, its more of a design issue. Jeremy since you "haven't yet decided exactly what semantics make sense here.".. My 2cents (which I realize no one has asked for but thats the beauty of internet mailing lists) is that by default for any writeable share the user & group on whos behalf Samba is acting should have the exact same permission to modify a file or delete it or whatever that they'd have where they actually logged into the Samba server via a UNIX shell. That is how I as a Systems Administrator have come to expect Samba to behave and to the best of my knowledge is how it does behave outside the particular issue we are discussing. As for the read only attribute on a file, I think if the user & group combination on who's behalf Samba is acting would have the ability to write to the file where they sitting at a UNIX shell then the read only flag should not be set and vice versa. > I'm at LinuxConfAu at the moment but 2619 isn't a real bug > as if you typed "attrib -r <filename>" it would fix the problem. > Only if dos filemode = yes By the way, this whole "issue" is not a new one. I set up this same scenario last night on an old Linux Mandrake 8 box running Samba 2.2.7a and the behavior was exactly the same. Tom Schaefer -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
