On 2019-08-14 19:40, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
>> You can often figure permissions problems
> I already figured where the problem was, in how cygwin convers (or, actually
> doesn't) the UNIX's "x" bit into the native DAC for the underlying filesystem
> (to store as, a
> This is called by acl_to_any_text, which is called by getfacl. Any
> chance you could try to debug this?
> I'm about to go on vacation, but I could try to help when I get back.
I'm headed out of town as well. But I get this very same EINVAL for any drive
(/cygdrive/X)
except for the local d
> You can often figure permissions problems
I already figured where the problem was, in how cygwin convers (or, actually
doesn't) the UNIX's "x" bit into
the native DAC for the underlying filesystem (to store as, again, "x" in the
Linux share). Missing that DAC, SMBD
returns "Access denied" for
On 8/14/2019 4:39 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> I also showed the "getfacl" output for that file and the directory above,
> which showed
> nothing additional.
getfacl failed with EINVAL, as you know. So you can't rely on its output.
Ken
--
Problem reports:
On 8/14/2019 10:07 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
wrote:
>249 98510 [main] getfacl 3412 __set_errno: char* __acltotext(aclent_t*,
> int, const char*, char, int):1644 setting errno 22
Here's where the EINVAL is coming from. The source is in sec_acl.cc:
char *
__acltot
On 2019-08-14 05:22, Ken Brown wrote:
> On 8/14/2019 12:23 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
>>> Have you checked the default ACL on the directory containing the file?
>>
>> No, and there's nothing special there now that I checked. I can change the
>> "Read & Execute" for
On Wed, 2019-08-14 at 23:22 +0300, Andrey Repin wrote:
> I've apparently missed something, but I can't seems to find CygLSA64.dll in
> recent cygwin packages.
> Was it deprecated/removed?
Yes:
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=0fb497165f8545470624012315aeaf37333c1ea2;
> See the '+' at the end of the modes?
I saw that, and I also showed the "getfacl" output for that file and the
directory above, which showed
nothing additional.
> Maybe, but we'd still need to know how to get to the result you're seeing.
Just take a samba server (4.x) and mount a share with de
Greetings, All!
I've apparently missed something, but I can't seems to find CygLSA64.dll in
recent cygwin packages.
Was it deprecated/removed?
--
With best regards,
Andrey Repin
Wednesday, August 14, 2019 23:09:49
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/p
> Feel free to provide a patch, just, please, create a valid git commit message
"getpriority() consistent with process priority
https://cygwin.com/ml/cygwin/2019-08/msg00122.html";
The changeset is really trivial:
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index a914ae8.
Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]!
>> What is your cygdrive mount options? Because default is, apparently,
>> "binary,posix=0,user".
> I have no idea where they are kept at, and how to change them.
This is, as I said, the DEFAULT.
To change them, edit /etc/fstab, add the desired l
On Wed, 14 Aug 2019 15:49:00 +0200
Corinna Vinschen wrote:
> The only reason I can see is if sigwait_common() returns EINTR because
> it was interrupted by an unrelated signal. This in turn lets the read()
> call fail with EINTR and that should be expected by the callers, in
> theory.
Strangely,
Веснин Юрий Александрович writes:
> It's definitely a bug. What's the proper way to fix it?
It's not a fix, but for starters you could create a bunch of smaller packages.
> Addition:
> @ rdc-deps
> sdesc: "RDC's devel dependencies"
> ldesc: "RDC's devel dependencies"
> category: Base
> requires:
Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin writes:
>> If it's related to the ACL handling then it should start working when
>> you remove the ACL on the file with 'setfacl -kb ...'
>
> There are no special ACLs set on the file (that was just produced by
> GCC from the source code, see my first
> I suspect the containing directory has a lot to do with it.
Please elaborate what you ground your suspicion on.
Like I said previously, I can add "Read & Execute" permissions to the file in
question from the Windows
file properties dialog, and it gets converted to an "x" on Linux side, then th
On Aug 14 20:47, Takashi Yano wrote:
> On Wed, 14 Aug 2019 20:41:00 +0900
> Takashi Yano wrote:
> > Hi Corinna,
> >
> > On Tue, 13 Aug 2019 12:47:53 +0200
> > Corinna Vinschen wrote:
> > > I created a patch which *seems* to do the right thing. I'm not
> > > yet sure it's the best solution, but it
On Wed, 14 Aug 2019 20:41:00 +0900
Takashi Yano wrote:
> Hi Corinna,
>
> On Tue, 13 Aug 2019 12:47:53 +0200
> Corinna Vinschen wrote:
> > I created a patch which *seems* to do the right thing. I'm not
> > yet sure it's the best solution, but it seems to do the trick, at
> > least.
> >
> > I'm ju
Hi Corinna,
On Tue, 13 Aug 2019 12:47:53 +0200
Corinna Vinschen wrote:
> I created a patch which *seems* to do the right thing. I'm not
> yet sure it's the best solution, but it seems to do the trick, at
> least.
>
> I'm just creating new developer snapshots, please try. I'll
> create another t
On 8/14/2019 12:23 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
>> Have you checked the default ACL on the directory containing the file?
>
> No, and there's nothing special there now that I checked. I can change the
> "Read & Execute" for the .exe file from the Windows file proper
>>> If you provide more details on that problem, I can probably give some
>>> advice.
>>
>> I suppose that bug comes from parsing setup.ini because of cygwin hangs on
>> such stage.
>> You can find more details by following previously described steps.
> You wrote: "We started to investigate setup
On Tue, 13 Aug 2019 23:50:54 +0200
Thorsten Kampe wrote:
> > I compiled tree
> > (http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz).
> >
> > Mintty: 2.5s
> > Cmd: 122s
> >
> > Make clean[1]:
> > Mintty: 0.3s
> > Cmd: 60,3s
>
> A second compile took even three minutes:
> real3m1,82
21 matches
Mail list logo
