On Fri, 17 Sep 2010 12:28:52 -0500 Steve French <[email protected]> wrote:
> On Fri, Sep 17, 2010 at 12:27 PM, Steve French <[email protected]> wrote: > > > > > > On Fri, Sep 17, 2010 at 12:15 PM, Jeff Layton <[email protected]> wrote: > >> > >> On Fri, 17 Sep 2010 13:00:05 -0400 > >> Jeff Layton <[email protected]> wrote: > >> > >> > I recently noticed a regression in samba in the last few weeks. Here's > >> > a simple way to reproduce it: > >> > > >> > 1) use smbclient to put a file on a samba share > >> > 2) change the mode of the file to something without the owner execute > >> > bit set > >> > 3) rename the file using smbclient > >> > > >> > When you do this, the newly renamed file will magically end up with the > >> > owner execute bit set. It seems like samba ought not be changing the > >> > mode of files when renaming them so I consider this a regression. > >> > > >> > I've reported the bug in the Fedora BTS, and attached some info there. > >> > Anyone more familiar with this code willing to have a look? > >> > > >> > https://bugzilla.redhat.com/show_bug.cgi?id=617771 > >> > > >> > I've was able to reproduce it today using the most recent samba version > >> > available in the Fedora repos (3.5.5). > >> > > >> > Thanks, > >> > >> Volker pointed out a workaround on IRC... > >> > >> If I set "map archive = no" then this doesn't seem to happen. So, I > >> guess something has happened relatively recently to make renames set > >> the archive bit? > > > > Interesting - but I would expect that rename would set the archive bit > > (creates, file modifications also set the bit in Windows). In Windows > > rename sets the archive bit (although we don't need to track the archive bit > > for Linux cifs.ko we probably could report it via xattrs for backup > > applications to use - much like Windows backup apps check/clear it). > > See below: > > C:\Users\stevef>echo newfile > new > > C:\Users\stevef>attrib new > > A C:\Users\stevef\new > > C:\Users\stevef>attrib -a new > > C:\Users\stevef>rename new newer > > C:\Users\stevef>attrib newer > > A C:\Users\stevef\newer > > -- > > Thanks, > > > > Steve > > Interesting - but I would expect that rename would set the archive bit > (creates, file modifications also set the bit in Windows). In Windows > rename sets the archive bit (although we don't need to track the archive bit > for Linux cifs.ko we probably could report it via xattrs for backup > applications to use - much like Windows backup apps check/clear it). > > See below: > > C:\Users\stevef>echo newfile > new > > C:\Users\stevef>attrib new > A C:\Users\stevef\new > > C:\Users\stevef>attrib -a new > > C:\Users\stevef>rename new newer > > C:\Users\stevef>attrib newer > A C:\Users\stevef\newer > > -- > Thanks, > > Steve Yeah, it makes some sense that this would happen in hindsight, but it's rather problematic in conjunction with unix extensions. The default of "map *" being on doesn't take into account clients that actually care about the mode remaining consistent across operations like rename. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
