On 2023-09-24 11:21, Martin Wege via Cygwin wrote:
Hello,
I tried to setuid an executable, so that it runs as user "SYSTEM", but
it does not work.
I tried this as an user with administrator rights:
chown SYSTEM:SYSTEM foo.exe
chmod u+s,g+s foo.exe
But running ./foo then just runs
Hello,
I tried to setuid an executable, so that it runs as user "SYSTEM", but
it does not work.
I tried this as an user with administrator rights:
chown SYSTEM:SYSTEM foo.exe
chmod u+s,g+s foo.exe
But running ./foo then just runs it as the current user.
What am I doing wrong?
Than
On Feb 10 11:42, Norton Allen via Cygwin wrote:
> On 2/9/2023 4:09 PM, Corinna Vinschen wrote:
> > On Feb 9 13:25, Norton Allen via Cygwin wrote:
> > > On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote:
> > > > [...]
> > > > The problem:
> > &g
users on one
machine can share full control over a particular directory hierarchy.
On Linux I have usually been able to make things work with:
$ mkdir shared_dir
$ chgrp shared_group shared_dir
$ chmod g+ws shared_dir
$ umask 2
User shells are configured with umask 2 so files they
sers on one
> > machine can share full control over a particular directory hierarchy.
> >
> > On Linux I have usually been able to make things work with:
> >
> > $ mkdir shared_dir
> > $ chgrp shared_group shared_dir
> > $ chmod g+ws shared_dir
>
usually been able to make things work with:
$ mkdir shared_dir
$ chgrp shared_group shared_dir
$ chmod g+ws shared_dir
$ umask 2
User shells are configured with umask 2 so files they create have
group write. Users belong to shared_group. Files and subdirs created
under shared_dir are all
shared_dir
$ chgrp shared_group shared_dir
$ chmod g+ws shared_dir
$ umask 2
User shells are configured with umask 2 so files they create have group
write. Users belong to shared_group. Files and subdirs created under
shared_dir are all in group shared_group. Files moved in retain their
On 7/10/2022 10:33 PM, Eliot Moss wrote:
On 7/10/2022 10:17 PM, Chris Wagner wrote:
On 6/29/2022 9:18 AM, Norton Allen wrote:
On one machine I have, chmod g+s fails to set the sticky bit.
The >>> command
does not return any error, but ls -l continues to show the bit
not set.
$
On 7/10/2022 10:17 PM, Chris Wagner wrote:
On 6/29/2022 9:18 AM, Norton Allen wrote:
On one machine I have, chmod g+s fails to set the sticky bit. The >>> command
does not return any error, but ls -l continues to show the bit not set.
$ mkdir foo
$ chgrp flight foo
$ c
On 6/29/2022 9:18 AM, Norton Allen wrote:
On one machine I have, chmod g+s fails to set the sticky bit. The
>>> command
does not return any error, but ls -l continues to show the bit not
set.
$ mkdir foo
$ chgrp flight foo
$ chmod g+ws foo
$ ls -ld foo
drwx
Greetings, Norton Allen!
> On 6/29/2022 9:18 AM, Norton Allen wrote:
>> On 6/29/2022 7:39 AM, Andrey Repin wrote:
>>> Greetings, Norton Allen!
>>>
>>>> On one machine I have, chmod g+s fails to set the sticky bit. The >>>
>>>> command
On 6/29/2022 9:18 AM, Norton Allen wrote:
On 6/29/2022 7:39 AM, Andrey Repin wrote:
Greetings, Norton Allen!
On one machine I have, chmod g+s fails to set the sticky bit. The
command
does not return any error, but ls -l continues to show the bit not set.
$ mkdir foo
$ chgrp flight
On 6/29/2022 7:39 AM, Andrey Repin wrote:
Greetings, Norton Allen!
On one machine I have, chmod g+s fails to set the sticky bit. The command
does not return any error, but ls -l continues to show the bit not set.
$ mkdir foo
$ chgrp flight foo
$ chmod g+ws foo
$ ls -ld foo
Greetings, Norton Allen!
> On one machine I have, chmod g+s fails to set the sticky bit. The command
> does not return any error, but ls -l continues to show the bit not set.
> $ mkdir foo
> $ chgrp flight foo
> $ chmod g+ws foo
> $ ls -ld foo
> drwxrw
On one machine I have, chmod g+s fails to set the sticky bit. The
command does not return any error, but ls -l continues to show the bit
not set.
$ mkdir foo
$ chgrp flight foo
$ chmod g+ws foo
$ ls -ld foo
drwxrwxr-x+ 1 nort flight 0 Jun 29 06:50 foo
I ran strace, and it looks
On Sat, Apr 17, 2021 at 8:11 PM Kaz Kylheku (Cygwin)
<743-406-3...@kylheku.com> wrote:
>
> On 2021-04-08 21:34, Orgad Shaneh via Cygwin wrote:
> > On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin
> > wrote:
> >>
> >> Greetings, Orgad Shaneh!
> >>
> >> > On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wro
On 2021-04-17 11:11, Kaz Kylheku (Cygwin) via Cygwin wrote:
On 2021-04-08 21:34, Orgad Shaneh via Cygwin wrote:
On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin wrote:
Why? If I report a bug, I'm interested in this bug, and I don't want
to receive dozens of emails every day about other issues.
The
On 2021-04-08 21:34, Orgad Shaneh via Cygwin wrote:
On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin
wrote:
Greetings, Orgad Shaneh!
> On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote:
> Marco Atzeri replied to the mailing list but did not CC me, so I
> didn't receive it:
The expectation is th
On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin wrote:
>
> Greetings, Orgad Shaneh!
>
> > On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote:
> >>
> >> Hi,
> >>
> >> If a filesystem is mounted with noacl, calling chmod to add write
> >
Greetings, Orgad Shaneh!
> On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote:
>>
>> Hi,
>>
>> If a filesystem is mounted with noacl, calling chmod to add write
>> permissions after umasking this permission doesn't work. Demonstrated
>> with command-li
On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote:
>
> Hi,
>
> If a filesystem is mounted with noacl, calling chmod to add write
> permissions after umasking this permission doesn't work. Demonstrated
> with command-line and C++.
>
> Did I miss something or is this a
On 07.04.2021 22:47, Orgad Shaneh via Cygwin wrote:
Hi,
If a filesystem is mounted with noacl, calling chmod to add write
permissions after umasking this permission doesn't work. Demonstrated
with command-line and C++.
Did I miss something or is this a real bug? According to umask ma
Hi,
If a filesystem is mounted with noacl, calling chmod to add write
permissions after umasking this permission doesn't work. Demonstrated
with command-line and C++.
Did I miss something or is this a real bug? According to umask man, it
should only affect newly created files and direct
On 2020-12-24 14:56, Ken Brown via Cygwin wrote:
Could the problem be that the owner and group are the same? You can
do that on unix, but I'm not sure the Windows security model allows
it. For example, what happens when you remove permissions of the
owner kaz while retaining the permissions of
On 12/24/2020 4:30 PM, Kaz Kylheku via Cygwin wrote:
Initial conditions:
0:BLACKBOX:~/txr$ rm testfile
0:BLACKBOX:~/txr$ touch testfile
0:BLACKBOX:~/txr$ chmod = testfile
0:BLACKBOX:~/txr$ ls -l testfile
-- 1 kaz kaz 0 Dec 24 13:23 testfile
Now, light up all the bits
a file is created, and permissions set as follows:
0:DESKTOP-K8055OB:~$ touch tempfile
0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
0:DESKTOP-K8055OB:~$ ls -l tempfile
-rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
Then "chmod u=" is not able to clear the owner's permissions t
Initial conditions:
0:BLACKBOX:~/txr$ rm testfile
0:BLACKBOX:~/txr$ touch testfile
0:BLACKBOX:~/txr$ chmod = testfile
0:BLACKBOX:~/txr$ ls -l testfile
-- 1 kaz kaz 0 Dec 24 13:23 testfile
Now, light up all the bits, like a Christmas tree---appropriate
for December 24:
0
:DESKTOP-K8055OB:~$ touch tempfile
0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
0:DESKTOP-K8055OB:~$ ls -l tempfile
-rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
Then "chmod u=" is not able to clear the owner's permissions to
nothing:
0:DESKTOP-K8055OB:~$ chmod u= tempfile
0:DESKTO
On 2020-10-10 14:51, Brian Inglis wrote:
D/ACLs on the directory could restore/maintain the permissions:
could we please see the output from ls -l, getfacl, and icacls on the
directory
and file?
Thanks for your responses, Ken and Brian.
See what you can make of this:
0:DESKTOP-K8055OB:~$ ls
3.1.7(0.340/5/3) 2020-08-22 19:03 i686
>> Cygwi
>>
>> When a file is created, and permissions set as follows:
>>
>> 0:DESKTOP-K8055OB:~$ touch tempfile
>> 0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
>> 0:DESKTOP-K8055OB:~$ ls -l tempfile
>> -rws
:DESKTOP-K8055OB:~$ touch tempfile
0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
0:DESKTOP-K8055OB:~$ ls -l tempfile
-rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
Then "chmod u=" is not able to clear the owner's permissions to nothing:
0:DESKTOP-K8055OB:~$ chmod u= tempfi
Hi all,
Running this Cygwin on a Windows 10 system:
0:DESKTOP-K8055OB:~$ uname -a
CYGWIN_NT-10.0-WOW DESKTOP-K8055OB 3.1.7(0.340/5/3) 2020-08-22 19:03
i686 Cygwi
When a file is created, and permissions set as follows:
0:DESKTOP-K8055OB:~$ touch tempfile
0:DESKTOP-K8055OB:~$ chmod
Greetings, Steven Penny!
> With Linux, these commands produce expected results:
> $ cd /tmp
> $ touch alpha.txt
> $ test -r alpha.txt; echo "$?"
> 0
> $ chmod -r alpha.txt
> $ test -r alpha.txt; echo "$?"
> 1
> $ chm
Am 23.12.2018 um 06:59 schrieb Steven Penny:
With Linux, these commands produce expected results:
$ cd /tmp
$ touch alpha.txt
$ test -r alpha.txt; echo "$?"
0
$ chmod -r alpha.txt
$ test -r alpha.txt; echo "$?"
1
$ chmod +r alpha.txt
$ tes
With Linux, these commands produce expected results:
$ cd /tmp
$ touch alpha.txt
$ test -r alpha.txt; echo "$?"
0
$ chmod -r alpha.txt
$ test -r alpha.txt; echo "$?"
1
$ chmod +r alpha.txt
$ test -r alpha.txt; echo "$?"
0
However with
> I'm trying to use Cygwin on a Windows machine with the latest release.
> The system in question must run from a filesystem formatted with FAT32
> and therefore inherits the 'noacl' field according to the documentation.
>
> After a clean install and running Cygwin.bat, I am greeted with the
>
ocket.c of
screen's source code but I'm not sure.
I have read a number of comments online about these permission errors
for both Cygwin and various Linux installations. All of them recommend
either setting the permissions to 777 with chmod or altering the NTFS
permissions, both of which has no af
On Nov 30 09:23, Ben Altman wrote:
> On 11/28/2016 7:00 PM, L. A. Walsh wrote:
> > Ben Altman wrote: When I get a directory listing, it shows for each
> > > file "Unknown+User Unknown+Group" while on the desktop the same files
> > > show my user name that I logged in with and "Domain Users" as the
On 11/28/2016 7:00 PM, L. A. Walsh wrote:
Ben Altman wrote: When I get a directory listing, it shows for each
file "Unknown+User Unknown+Group" while on the desktop the same files
show my user name that I logged in with and "Domain Users" as the
group.
---
Is your laptop a member of the dom
Ben Altman wrote:
When I log in to my account at work I get access to a network location
accessed as a drive dedicated to me. I log in from 2 locations - my
laptop and desktop.
---
Were both setup by your company's IT department, or
if not, who? Are they both running the same version of
When I log in to my account at work I get access to a network location
accessed as a drive dedicated to me. I log in from 2 locations - my
laptop and desktop. Directory listings and chmod work as expected on
the desktop but when I try to do a chmod on the laptop, it fails for
the user&#
On May 19, 2016, at 7:01 PM, Warren Young wrote:
>
> For what it’s worth, setfacl -bk followed by a chmod -x sometimes always
> fixes this.
I’ve solved this by applying that fix to the affected directory trees in bulk:
$ find foo bar baz -exec setfacl -kb {} \;
Heavy-hande
I think I have an ACL inheritance problem. Here’s the scenario:
$ ls -l Protocol.md ## Boo, bad permissions; shouldn’t be +x!
-rwxr--r--+ 1 Warren Warren 4.3K May 19 18:41 Protocol.md*
$ chmod -x Protocol.md
$ ls -l Protocol.md ## Still +x! Did I stutter?
-rwxr--r--+ 1 Warren
t;>>update procedure before I notified the chmod error.
> >>>>A months ago, I had to migrate to the new AD account. The cygwin was
> >>>>installed using my old account, which is deleted now. Is it possible that
> >>>>the query to AD runs
On 04/20/2016 04:25 PM, Corinna Vinschen wrote:
On Apr 20 15:05, Tomas Jura wrote:
On 04/19/2016 03:39 PM, Corinna Vinschen wrote:
BTW: My machine is Windows Server 2008, yesterday I also run the Windows
update procedure before I notified the chmod error.
A months ago, I had to migrate to the
On Apr 20 15:05, Tomas Jura wrote:
> On 04/19/2016 03:39 PM, Corinna Vinschen wrote:
> >>BTW: My machine is Windows Server 2008, yesterday I also run the Windows
> >>update procedure before I notified the chmod error.
> >>A months ago, I had to migrate to the
On 04/19/2016 03:39 PM, Corinna Vinschen wrote:
BTW: My machine is Windows Server 2008, yesterday I also run the Windows
update procedure before I notified the chmod error.
A months ago, I had to migrate to the new AD account. The cygwin was
installed using my old account, which is deleted now
-3229423371-1046061999-513:513:
This is group 513 of the local SAM. This is not related.
> BTW: My machine is Windows Server 2008, yesterday I also run the Windows
> update procedure before I notified the chmod error.
> A months ago, I had to migrate to the new AD account. The cygwin was
>
:513:
BTW: My machine is Windows Server 2008, yesterday I also run the Windows
update procedure before I notified the chmod error.
A months ago, I had to migrate to the new AD account. The cygwin was
installed using my old account, which is deleted now. Is it possible
that the query to AD run
On Apr 19 09:22, Tomas Jura wrote:
> Hi
>
> I got error chmod on config.lock failed: Invalid argument and I was able to
> catch the strace. It is attached.
What I see from the strace, chmod fails to request group information:
299755 597014 [main] chmod 5840 internal_getlogin: gro
Hi
I got error chmod on config.lock failed: Invalid argument and I was
able to catch the strace. It is attached.
I had a suspicion to locales, but with the LC_ALL=C chmod 777
x
Use CC: to my email address for any questions or requests for testing.
I'm not in the mailing list.
On Feb 10 11:59, Rainer Blome wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 08.02.2016 15:29, Corinna Vinschen wrote:
> > On Jan 31 21:24, Rainer Blome wrote:
> >> On 28.01.2016 21:40, Corinna Vinschen wrote:
> > On a hunch, do you have old /etc/passwd and /etc/group
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08.02.2016 15:29, Corinna Vinschen wrote:
> On Jan 31 21:24, Rainer Blome wrote:
>> On 28.01.2016 21:40, Corinna Vinschen wrote:
> On a hunch, do you have old /etc/passwd and /etc/group
> files
There is no `/etc/group`, but `/etc/pass
method.
>
> On my Cygwin 2.4.1, to get things to run the way I want them, I
> renamed `/etc/passwd.renamed` back to `/etc/passwd`, and replaced
> the old group id by the ID of group "None", 197121.
> In a new terminal, things now run as expected, SSH finds its .ssh
> dire
passwd`. Since it is small,
I see no harm in using this method.
On my Cygwin 2.4.1, to get things to run the way I want them, I
renamed `/etc/passwd.renamed` back to `/etc/passwd`, and replaced
the old group id by the ID of group "None", 197121.
In a new terminal, things now run as expect
Does moving them out of /etc (don't delete them for now!),
> > exiting from Cygwin and starting a new shell somehow fix things for you?
> > How do the files look like?
>
> Define "old"! ;-) Yes, I do. There is no `/etc/group`, but
> `/etc/passwd` defines the group ID
nce? Does moving them out of /etc (don't delete them for now!),
> exiting from Cygwin and starting a new shell somehow fix things for you?
> How do the files look like?
Define "old"! ;-) Yes, I do. There is no `/etc/group`, but
`/etc/passwd` defines the group ID of my user as 213
On Jan 28 17:11, Rainer Blome wrote:
> > Gesendet: Donnerstag, 28. Januar 2016 um 15:33 Uhr
> > Von: "Corinna Vinschen"
> > Also, an strace of chmod, e.g.
> >
> > $ strace -o chmod.strace chmod 777 x
> >
> > might be helpful. Please send
On Jan 28 17:06, Rainer Blome wrote:
> > Corinna Vinschen wrote 2016-01-28 15-44:
> > On Jan 28 15:24, Rainer Blome wrote:
> >
> > The "In-Reply-To" is still missing in your mails, so you're invariably
> > breaking threading. T'would be nice if you could make your mailer
> > behave :)
>
> This is
> Gesendet: Donnerstag, 28. Januar 2016 um 15:33 Uhr
> Von: "Corinna Vinschen"
> Also, an strace of chmod, e.g.
>
> $ strace -o chmod.strace chmod 777 x
>
> might be helpful. Please send the file chmod.strace with your reply.
$ strace -o chmod.strace chmod 7
e that I have a mail to reply to,
hope the threading is preserved now.
> > > Corinna Vinschen wrote:
> > > On Jan 28 01:27, Christopher Cobb wrote:
> > >> Or maybe chmod is broken, like it is on my machine:
> > >> $ chmod 777 x
> > >> chmod: ch
you could make your mailer
behave :)
> > Corinna Vinschen wrote:
> > On Jan 28 01:27, Christopher Cobb wrote:
> >> Or maybe chmod is broken, like it is on my machine:
> >> $ chmod 777 x
> >> chmod: changing permissions of âxâ: Invalid argument
>
> >
t; > > done.
> > > > >
> > > > >When I use the same command on my Cygwin 64 installation, this used
> > > > >to work, but does not work any more. I can fetch and otherwise use
> > > > >Git in existing repos all right (have not
Rainer, please make sure your mailer doesn't break threading. I tweaked
the "In-Reply-To" now to return to the original thread on the mailing
list. Thank you.
On Jan 28 14:44, Rainer Blome wrote:
> Christopher Cobb wrote on Thu, 28 Jan 2016 01:27:16 +0100:
> > Or maybe
(Apologies for not using the reply feature, I was not
subscribed when the last mail was sent. I am now subscribed.)
> Corinna Vinschen wrote:
> On Jan 28 01:27, Christopher Cobb wrote:
>> Or maybe chmod is broken, like it is on my machine:
>> $ chmod 777 x
>> chmod: cha
Christopher Cobb wrote on Thu, 28 Jan 2016 01:27:16 +0100:
> Or maybe chmod is broken, like it is on my machine
You nailed it, thanks! Indeed, `chmod` appears to always fail,
on any file. Git tries to use it, and that fails.
cd
touch foo
ls -l foo
-rwx-- 1 myusername 213 0 Jan 28 14
Greetings, Christopher Cobb!
> Or maybe chmod is broken, like it is on my machine:
> $ touch x
> $ chmod 777 x
> chmod: changing permissions of ‘x’: Invalid argument
Please provide details according to
> Problem reports: http://cygwin.com/problems.html
And please r
llation, this used
> > > >to work, but does not work any more. I can fetch and otherwise use
> > > >Git in existing repos all right (have not noticed anything else
> > > >amiss), but the clone command fails like this:
> > > >
> > > >
&
Or maybe chmod is broken, like it is on my machine:
$ touch x
$ chmod 777 x
chmod: changing permissions of ‘x’: Invalid argument
> Sent: Wednesday, January 27, 2016 at 9:53 AM
> From: "Corinna Vinschen"
> To: cygwin@cygwin.com
> Subject: Re: git clone fails with: error
>
> >When I use the same command on my Cygwin 64 installation, this used
> >to work, but does not work any more. I can fetch and otherwise use
> >Git in existing repos all right (have not noticed anything else
> >amiss), but the clone command fails like this:
>
re. I can fetch and otherwise use
Git in existing repos all right (have not noticed anything else
amiss), but the clone command fails like this:
cd /cygdrive/c/base
git clone foo bar
Cloning into 'bar'...
error: chmod on /cygdrive/c/base/bar/.git/config.lock failed: Invalid argument
er
ting repos all right (have not noticed anything else
amiss), but the clone command fails like this:
cd /cygdrive/c/base
git clone foo bar
Cloning into 'bar'...
error: chmod on /cygdrive/c/base/bar/.git/config.lock failed: Invalid argument
error: chmod on /cygdrive/c/base/bar/.git/config
Hello,
I'm using cygwin 64bit on Windows 7.
I'm using X-emacs under cygwin.
In emacs I use eshell.
When I open text file and modify it and then save I have this error:
Error: (file-error "doing chmod" "permission denied" "")
I followed all instructions t
Well well -- making that fstab change alone (and rebooting) seems to have fixed
it! Release notes says:
Since 1.7.34, chmod does not always affect the POSIX permission mask as
returned by stat(2) or printed by ls(1), due to the improved POSIX ACL
handling. However, that's still far
Greetings, Phil Smith!
>>Please use Cygwin paths with Cygwin tools.
>>Windows paths are not guaranteed to work with every Cygwin tool.
> This is scripted, and while I can hack it to use Cygwin paths, it probably
> shouldn't be lying to me, saying that it worked. And it did work before,
> still do
Thanks for the reply. Some thoughts:
>Please use Cygwin paths with Cygwin tools.
>Windows paths are not guaranteed to work with every Cygwin tool.
This is scripted, and while I can hack it to use Cygwin paths, it probably
shouldn't be lying to me, saying that it worked. And it did work before, s
Greetings, Phil Smith!
> The short description is that chmod *with a path* says it works, but
> doesn't. If I cd to the directory and do it from there, it works.
> This behavior *seems* to have started recently, after I installed gawk (and
> in the process updated some other
The short description is that chmod *with a path* says it works, but doesn't.
If I cd to the directory and do it from there, it works.
This behavior *seems* to have started recently, after I installed gawk (and in
the process updated some other Cygwin bits). Our scaffolding for some
es, as far as I can tell)
> >
> > Yeah, I noticed that problem myself a few hours ago and applied a fix in
> > the meantime. In CVS, the chmod workaround does not touch the CREATOR
> > OWNER, CREATOR GROUP and Everyone default ACEs anymore. I'll create a
>
;-)
>>
>> For a directory, the 'creator owner' should have sufficient permissions.
>> That is, at least 'full control
>> minus delete'; full control is good. (yes, as far as I can tell)
>
> Yeah, I noticed that problem myself a few hours ago and ap
27;creator owner' should have sufficient permissions. That
> is, at least 'full control
> minus delete'; full control is good. (yes, as far as I can tell)
Yeah, I noticed that problem myself a few hours ago and applied a fix in
the meantime. In CVS, the chmod workaround d
27;full control
minus delete'; full control is good. (yes, as far as I can tell)
(with respect to setfacl, I made a similar remark)
That has changed in 1.7.35-0.4 with respect to chmod ...
As result one cannot 'touch' (create) a file in a subdirectory, that has been
created using E
; All my file permissions that were correctly reported by ls -l as
> >> rw-r--r-- became all of a sudden -rw-rwxr--+ ??? The same for
> >> directories where all previously 755 dirs came back as drwxrwxr-x+
> >>
> >>
> >> ...
> >> % chmod 644 bu
On Feb 9 22:00, diod lightbulb wrote:
> However, I'd like to ask somthing else, is there a way to make newly
> created files outside my home to respect my umask? I just tried touch
> still buggy; ll stillbuggy reports -rw-rwxr--+ while stat -c " %a %u
> %g" stillbuggy gives back " stillbuggy
Greetings, diod lightbulb!
> All I can do now is apparently to run all my pre-existing files thru
> setfacl -b (I like to keep my files with 644 permissions) followed by
> chmod. I just have to figure out how to retain the execution bit for
> the few select executables that need it
t; rw-r--r-- became all of a sudden -rw-rwxr--+ ??? The same for
>> directories where all previously 755 dirs came back as drwxrwxr-x+
>>
>>
>> ...
>> % chmod 644 buggy
>> % stat -c " %a %u %g" buggy
>> " buggy 674 1000 545
>>
>>
directories were created by
cygwin-related apps
b- After your fix, the ACLs struck back in non-cygwin generated files.
Unfortunately, even if I took care chmod'ing (644) nearly all my
files, the ACLs got rid of all that.
All I can do now is apparently to run all my pre-existing files thru
set
came back as drwxrwxr-x+
...
% chmod 644 buggy
% stat -c " %a %u %g" buggy
" buggy 674 1000 545
Oooch, no change??? chmod used to work before today (BTW, same
behavior for pre-existing files: chmod has no effect).
...
See my mail about "group permissions". This would reso
On Feb 9 16:37, diod lightbulb wrote:
> HI all,
>
> Maybe this is a regression. This is linked to the problem reported in
> this other thread https://cygwin.com/ml/cygwin/2015-02/msg00100.html .
> I took notice of
> it right after I updated cygwin (setup.exe 2.867) today.
Does https://cygwin.com
eb 7 20:07 buggy*
% stat -c " %a %u %g" buggy
" buggy 674 1000 545
What the hell? I expected 644.
% chmod 644 buggy
% stat -c " %a %u %g" buggy
" buggy 674 1000 545
Oooch, no change??? chmod used to work before today (BTW, same
behavior for pre-existing files: c
Hi.
From cygwin shell I'm able to read and write files even though my
Windows user has no permission for it. I tried `chmod` and to deny
everything for Everyone in the Windows dialog, but it didn't help. How
is it possible?
$ id
uid=48466(basin) gid=545(Users)
groups=545(Use
On 12/30/2013 2:23 PM, Nellis, Kenneth wrote:
From: bartels
On 12/30/2013 06:16 AM, Nithin Kurien wrote:
When I type the following sequence of commands:
cd ~; mkdir sample; chmod -R 0700 sample; stat -c "%a %u %g" sample;
rm -rf sample; mkdir sample; chmod -R 0755 sample; stat -c
From: bartels
>
> On 12/30/2013 06:16 AM, Nithin Kurien wrote:
> > When I type the following sequence of commands:
> >
> > cd ~; mkdir sample; chmod -R 0700 sample; stat -c "%a %u %g" sample;
> > rm -rf sample; mkdir sample; chmod -R 0755 sample; stat -c
On 12/30/2013 06:16 AM, Nithin Kurien wrote:
When I type the following sequence of commands:
cd ~; mkdir sample; chmod -R 0700 sample; stat -c "%a %u %g" sample;
rm -rf sample; mkdir sample; chmod -R 0755 sample; stat -c "%a %u %g"
sample
the output is:
770 1001 513
775 10
When I type the following sequence of commands:
cd ~; mkdir sample; chmod -R 0700 sample; stat -c "%a %u %g" sample;
rm -rf sample; mkdir sample; chmod -R 0755 sample; stat -c "%a %u %g"
sample
the output is:
770 1001 513
775 1001 513
Why is chmod not working?
OS: Windows
Drew Adams writes:
> I have read various info regarding trying to make Cygwin's `chmod'
> work as (I) expected, including the Cygwin FAQ and user guide.
> I am using Windows 7 with an NTFS disk. My user and group are
> defined as they should be AFAIK.
>
> Two questio
On 8/7/2013 2:33 PM, Drew Adams wrote:
I have read various info regarding trying to make Cygwin's `chmod'
work as (I) expected, including the Cygwin FAQ and user guide.
I am using Windows 7 with an NTFS disk. My user and group are
defined as they should be AFAIK.
Two questions in t
I have read various info regarding trying to make Cygwin's `chmod'
work as (I) expected, including the Cygwin FAQ and user guide.
I am using Windows 7 with an NTFS disk. My user and group are
defined as they should be AFAIK.
Two questions in this regard:
. is "chmod a-w"
On Apr 5 05:37, Karl M wrote:
> On Apr 5 14:25, Corinna Vinschen wrote:
> > It works still fine for me if I don't use the same Windows group as
> > owner and as group of the file.
>
> Btw., there were no changes at all between 1.7.10 and 1.7.12 which
> would even
; of the SID S-1.5.32.544 having rw- permissions.
> > >
> > > Apart from that, the owner of the /etc/ssh* files should be cyg_server,
> > > not the admins group.
> > >
> > I name my cyg_server user root.
>
> But your root group is the same as the
1 - 100 of 427 matches
Mail list logo
