Menu

#1475 chmod broken (does not modify acl)

MSYS
closed
nobody
None
wont-fix
Known_Feature
2014-08-06
2010-09-19
No

As recently reported on mailing list: http://thread.gmane.org/gmane.comp.gnu.mingw.msys/4721/focus=4732

$ touch test.txt
$ chmod +x test.txt
$ ls -l test.txt
-rw-r--r-- 1 marcin Administ 0 Sep 19 22:24 test.txt

$ uname -a
MINGW32_NT-6.1 XXX-PC 1.0.12(0.46/3/2) 2010-02-05 01:08 i686 unknown

Using msys from msysgit or msys-base-2010080900 on Windows 7.

I've found the code of chmod where it looks like it should be supported if acl is enabled on filesystem, however it seems to be disabled by default and there is no way to enable it.

Discussion

  • Keith Marshall

    Keith Marshall - 2010-10-11
    • status: open --> closed-wont-fix
     
  • Keith Marshall

    Keith Marshall - 2010-10-11

    Unlike POSIX, MS-Windows doesn't use mode flags to mark a file as executable, so there is no way 'chmod -x' can ever do anything useful on the MSYS platform. Furthermore, the POSIX group and other-user attributes do not map cleanly to MS-Windows file system attributes, and since MS-Windows doesn't support any concept of a file which is accessible but not readable, MSYS chmod cannot really be expected to do anything beyond toggle the owner's write enable attribute.

    Certainly, as you note, GNU chmod includes code to manipulate ACLs, but that is intended to work with GNU/Linux ACLs, with which MS-Windows/NTFS ACLs are grossly incompatible; modifying the code to manipulate such ACLs goes way beyond our design goals for MSYS, so I'm sorry, but this is a definite "won't fix".

     
  • Marcin Wisnicki

    Marcin Wisnicki - 2010-10-11

    It can and should do something useful. It certainly does on cygwin.

    I don't know what you mean by accessible but not readable. If accessible=executable then you can have that. As you note there is no clean mapping for every case but all I want is preservation of executable attribute for owner and for everyone else (group+other) which is needed for working with typical unix sources, where scripts have to keep their executable attribute when sharing code (e.g. with git).

    The code of chmod (I was talking about syscall not a utility) is very much windows only: [syscalls.cc] from line 803, at 843 calls set_file_attribute() in [security.cc]:1589, which calls alloc_sd() that does conversion of unix mode to nt security descriptor starting with line 1381 of [security.cc]

    Unfortunately, it does not work, most likely because it is stopped at [security.cc]:1595.

    References:
    [syscalls.cc] http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/syscalls.cc?revision=1.18&view=markup
    [security.cc] http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/security.cc?revision=1.3&view=markup

     
  • Marcin Wisnicki

    Marcin Wisnicki - 2010-10-11

    Hmm... though it seems that I should be covered with emulation of executable bit when file starts with #!. Looks like mingw git is not really using stat/chmod from msys but something else. So I guess I should bother them, not you.

     
  • Keith Marshall

    Keith Marshall - 2010-10-11

    It cannot do anything more useful than it already does, unless it fakes it in the POSIX emulation, as Cygwin does. However, what Cygwin does is mostly irrelevant; since MSYS was forked from Cygwin-1.3, most of that faking was *deliberately* disabled -- it *isn't* an objective of MSYS, to provide faked POSIX features to the extent supported by Cygwin. If you want Cygwin's behaviour, and MSYS doesn't retain it sufficiently for your needs, then you should use Cygwin.

    MSYS is designed to better integrate with the *native* MS-Windows features supported by MinGW. In this native MS-Windows environment, there is no file system attribute which can mark a file as executable -- that is indicated by magic byte sequences within the file's data space, (and usually also qualified by a file name extension to match). There is no way MSYS chmod can safely modify that, without risk of file corruption, other than by more completely embracing Cygwin's emulation. However, that is diametrically opposed to the MSYS Project objectives -- it just ain't going to happen.

     
  • Earnie Boyd

    Earnie Boyd - 2013-01-23
    • labels: MSYS -->
    • status: closed-wont-fix --> closed
    • resolution: --> wont-fix
    • category: --> Known_Feature
    • milestone: --> MSYS
     
  • Steven Penny

    Steven Penny - 2014-08-06

    So can you explain this then?

    $ uname -a
    MINGW32_NT-6.1 STEVEN-PC 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
    
    $ install --help | grep MODE
      -m, --mode=MODE     set permission mode (as in chmod), instead of rwxr-xr-x
    
    $ touch foo.sh
    
    $ install foo.sh /bin
    
    $ ls -l /bin/foo.sh
    -rw-r--r-- 1 Steven Administrators 0 Aug  6 11:12 /bin/foo.sh
    
     
    • Keith Marshall

      Keith Marshall - 2014-08-06

      What is it that you'd like to have explained? You created an empty file, and installed it. It's both readable, (as it must be on Windows, because there is no concept of write-only here), and it is writable; it is not executable, because it has neither a recognized executable extension, nor does it contain a shebang magic number sequence, and Windows itself does not support the concept of an executable attribute flag.

      The output from ls tells you that the file is readable, writable, and not executable, through the owner attribute flags. Beyond that, the group and other-user flags are, at best, an estimate of what these would likely be on a *nix platform; don't waste your energy trying to read anything more into them.

      The MSYS chmod command can toggle the (single) read-only flag within the Windows directory entry, and no more. Within the declared objectives of the MinGW.org Project, there is no incentive to make it do more, and this is positively my last word on this ticket.

       
  • Steven Penny

    Steven Penny - 2014-08-06

    As yes the Old Guard, completely wrong and refuse to even discuss it. Anyway, if you insist on delivering a crippled product vis a vis "chmod" and "install", then the respective
    "--help" screens should reflect the crippled nature of both products, and not mislead the user into thinking they work how they should.

     

    Last edit: Steven Penny 2014-08-06