public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Eliot Moss <moss@cs.umass.edu>
To: cygwin@cygwin.com
Subject: Re: Filemode change by windows applications
Date: Wed, 28 Mar 2018 14:50:00 -0000	[thread overview]
Message-ID: <7f3fe599-eda0-2c97-b344-687b606615eb@cs.umass.edu> (raw)
In-Reply-To: <9965f4cf-566c-6d20-61b7-ce43580935aa@cs.umass.edu>

On 3/28/2018 10:40 AM, Eliot Moss wrote:
> On 3/28/2018 10:11 AM, Andrey Repin wrote:
> 
>>> and is there anything I can do to prevent windows
>>> applications from setting the execute bit on my files?
>>
>> No, and you will be unable to use Windows associations, if you clear execute bit
>> on documents.
> 
> Interesting that you think so, Andrey.  I just tested this on my Windows 10
> Surface Book.  I used Windows Explorer to navigate to a folder where I had
> cleared the x bits from a .docx file (setting mode to 660 with chmod in
> Cygwin), and clicking on the file opened Word on the file just fine.  Maybe
> this behavior is dependent on some other things as well?

Here is getfacl output for the file in question:

# file: Progress Letters S16.docx
# owner: moss
# group: moss
user::rw-
group::---
group:SYSTEM:r-x                        #effective:r--
group:Cygwin:rwx                        #effective:rw-
mask:rw-
other:---

So there are underlying x bits of some kind, but Cygwin does display
mode 660 via ls -l (for example).

Still, we entirely agree that there is not really a way to prevent a
Windows program from setting the x bits.  Here is getfacl from another
file in the same folder, reflecting how Word sets the permissions:

# file: Progress Letters S17.docx
# owner: moss
# group: moss
# flags: -s-
user::rwx
group::---
group:SYSTEM:r-x
group:Cygwin:rwx
mask:rwx
other:r-x

I think the key difference is "mask".

Regards - Eliot

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2018-03-28 14:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28  8:16 Kjetil Østerås
2018-03-28 13:37 ` Eliot Moss
2018-03-28 14:40   ` Kjetil Østerås
2018-03-28 16:20     ` Eliot Moss
2018-03-28 14:27 ` Andrey Repin
2018-03-28 14:45   ` Eliot Moss
2018-03-28 14:50     ` Eliot Moss [this message]
2018-03-28 16:56       ` Andrey Repin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f3fe599-eda0-2c97-b344-687b606615eb@cs.umass.edu \
    --to=moss@cs.umass.edu \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).