On 11/17/2014 10:08 AM, Torsten Bögershausen wrote: > On 11/17/2014 02:40 AM, Eric Sunshine wrote: >> On Sun, Nov 16, 2014 at 2:21 AM, Michael Haggerty >> <mhagger@xxxxxxxxxxxx> wrote: >>> [...] > Sorry for the late reply, I actually had prepared a complete different > patch > for a different problem, but it touches the very same lines of code. > > (And we may want to add a > !chmod(path, st1.st_mode & ~S_IXUSR) > at the end of the operation) > > There are systems when a file created with 666 have 766, and we > do not handle this situation yet. > > Michael, if there is a chance that you integrate my small code changes > in your patch ? Your change seems like a good idea, but is is logically separate from mine and I think it would be awkward to yoke them together. Both changes are short enough that conflict resolution shouldn't be a big problem. It will be easier for you to follow up on your patch if you submit it separately. The first question you get might be: "Should it be applied to maint or is it more suitable for master?", which also hints at one of the reasons that yoking the patches together might be awkward. Regarding your patch itself: > [...] > b) The user executable bit is always 1 > c) Is similar to b): > When a file is created with mode 0666 the file mode on disc is 766 > and the user executable bit is 1 even if it should be 0 like b) > > There are smbfs implementations where the file mode can be maintained > locally and chmod -x changes the file mode from 0766 to 0666. > When the file system is unmounted and remounted, > the file mode is 0766 and executable bit is 1 again. It seems surprising that there isn't also a case (d) like (c) except that a file created with mode 0666 initially has the correct mode, and the executable bits can be maintained locally while the filesystem is mounted, but where executable bits are lost whenever the filesystem is unmounted and remounted. Does that case not arise, or is it simply that it is impossible to test for it in create_default_files()? Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html