On Oct 27 23:30, Vermessung AVT - Wolfgang Rieger wrote:
> From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com]
> Sent: Tuesday, October 27, 2015 10:53
> To: cygwin@cygwin.com
> Subject: Re: gawk: Bad File Descriptor error with concurrent readonly access
> to a networ
From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com]
Sent: Tuesday, October 27, 2015 10:53
To: cygwin@cygwin.com
Subject: Re: gawk: Bad File Descriptor error with concurrent readonly access to
a network file
(Snip)
> Cygwin uses full sharing for all files it opens, unless the file is ope
On Oct 27 06:48, Matt D. wrote:
> I haven't had an opportunity to look into it but I've also encountered
> errors when performing a parallel make build (make -j) on a large C++
> project which has multiple interdependencies across a network share with too
> many threads.
>
> The reported "Bad File
I haven't had an opportunity to look into it but I've also encountered
errors when performing a parallel make build (make -j) on a large C++
project which has multiple interdependencies across a network share with
too many threads.
The reported "Bad File Descriptor" is the same error that I ge
On Sep 25 16:31, Vermessung AVT - Wolfgang Rieger wrote:
> 1) Concurrent read access to the setup files was possible and worked
> fine with local files (24 hrs testing with millions of file accesses
> in 4 parallel jobs).
> 2) However, when the file to be read (datafile.txt) is stored on a
> networ
. September 2015 12:01
To: 'cygwin@cygwin.com'
Subject: Re: gawk: Bad File Descriptor error with concurrent readonly access to
a network file
On Fri, 25 Sep 2015 18:58:57 +0200, Marco Atzeri wrote:
>> "Bad file descriptor" just arose recently in another problem
>> http
Greetings, Marco Atzeri!
Can you provide the type of network disk with
/usr/lib/csih/getVolInfo
>> I am sorry, I have a very small installation of Cygwin running with no
>> getVolInfo. In which package can I find that? We have MS Windows Server 2008
>> that provides network shares.
>>
On 26/09/2015 12:00, Vermessung AVT - Wolfgang Rieger wrote:
On Fri, 25 Sep 2015 18:58:57 +0200, Marco Atzeri wrote:
Can you provide the type of network disk with
/usr/lib/csih/getVolInfo
I am sorry, I have a very small installation of Cygwin running with no
getVolInfo. In which package can
On Fri, 25 Sep 2015 18:58:57 +0200, Marco Atzeri wrote:
>> "Bad file descriptor" just arose recently in another problem
>> https://cygwin.com/ml/cygwin/2015-09/msg00374.html
>> https://cygwin.com/ml/cygwin/2015-09/msg00436.html
>>
I don't think this applies to our case. We use massive parallel proc
On 25/09/2015 18:31, Vermessung AVT - Wolfgang Rieger wrote:
We let thousands of tiles undergo the same time consuming processing tasks. We use a
multi core Windows 7 workstation running several tiles simultaneously in separate shell
windows (parallel processing). A batch script controls the wo
We let thousands of tiles undergo the same time consuming processing tasks. We
use a multi core Windows 7 workstation running several tiles simultaneously in
separate shell windows (parallel processing). A batch script controls the work
flow of the task with gawk interpreting a number of setup /
On Sep 3 10:38, Vince Indriolo wrote:
> Interesting, the location of the file seems to matter.
> [...]
> For a file on my desktop:
> $ ls -l foo
> -rwx--+ 1 vince None 6 Sep 3 10:28 foo
> $ ls -l .\\foo
> -rw-r--r-- 1 vince None 6 Sep 3 10:28 .\foo
It's not the location, it'
Interesting, the location of the file seems to matter.
On E:\
$ ls -l foo
--+ 1 vince None 6 Sep 3 10:27 foo
$ ls -l .\\foo
-rw-r--r-- 1 vince None 6 Sep 3 10:27 .\foo
For a file on my desktop:
$ ls -l foo
-rwx--+ 1 vince None 6 Sep 3 10:28 foo
$ ls -l .
Vince Indriolo gmail.com> writes:
> There is definitely something not right with my setup. I have 64-bit Windows
> 7
>
> e:\>echo foo > foo
> e:\>c:\cygwin\bin\ls.exe -l foo
> --+ 1 vince None 6 Sep 2 17:28 foo
>
> $ ls -l foo
> --+ 1 vince None 6 Sep 2 17:28 foo
Interestin
s again,
Vince
On Wed, Sep 2, 2009 at 5:14 PM, Larry Hall
(Cygwin) wrote:
> On 09/02/2009 06:06 PM, Vince Indriolo wrote:
>>
>> Thanks, Larry. What I mean by external file is a file created by
>> Windows (not created in the cygwin environment). Files that are
>> writa
On 09/02/2009 06:06 PM, Vince Indriolo wrote:
Thanks, Larry. What I mean by external file is a file created by
Windows (not created in the cygwin environment). Files that are
writable in windows appear to be readonly (000) in the bash shell. I
assume that because they're owned by me
Thanks, Larry. What I mean by external file is a file created by
Windows (not created in the cygwin environment). Files that are
writable in windows appear to be readonly (000) in the bash shell. I
assume that because they're owned by me I can chmod them to modify
them.
On Wed, Sep 2, 20
On 09/02/2009 05:30 PM, Vince Indriolo wrote:
Is there a setting or issue that would result in all externally
generated files in an NTFS filesystem to have 000 permissions? New
files created in the shell appear to have the correct mask. However,
I need to chmod every external file I want to mod
Is there a setting or issue that would result in all externally
generated files in an NTFS filesystem to have 000 permissions? New
files created in the shell appear to have the correct mask. However,
I need to chmod every external file I want to modify.
Also, is it intended for my user account t
I am running Windows 7, cygdrive 1.7.
After installation all files my files show up as 000 permissions. I
have to chmod in order to modify files.
vi...@granada /cygdrive/f
$ ls -l
total 852
d-+ 1 vinceNone 4096 Aug 25 08:58 $RECYCLE.BIN
d-+ 1 vince None
Corinna Vinschen wrote:
On Aug 28 19:57, Christian Franke wrote:
This is not true when 'chmod -w ...' was done before the upgrade to 1.7.
Cygwin 1.5 sets R/O attribute, then open for write fails with permission
denied also on 1.7.
That's why 1.7 tries not to set the R/O DOS attribute
On Aug 28 19:57, Christian Franke wrote:
> Dave Korn wrote:
>> Christian Franke wrote:
>>
>>> For members of Admin group, Cygwin 1.7 allows to overwrite files without
>>> write permission, but Cygwin 1.5 does not.
>>>
>>
>> You are the root user, this is Unix. Of course you can overwrite
Dave Korn wrote:
Christian Franke wrote:
For members of Admin group, Cygwin 1.7 allows to overwrite files without
write permission, but Cygwin 1.5 does not.
You are the root user, this is Unix. Of course you can overwrite files
without write permission.
This is not true when '
Christian Franke wrote:
> For members of Admin group, Cygwin 1.7 allows to overwrite files without
> write permission, but Cygwin 1.5 does not.
You are the root user, this is Unix. Of course you can overwrite files
without write permission.
> Is this a intended change of 1.7 ?
Yep, think so
For members of Admin group, Cygwin 1.7 allows to overwrite files without
write permission, but Cygwin 1.5 does not.
Is this a intended change of 1.7 ?
I would suggest to add a note to
http://cygwin.com/1.7/cygwin-ug-net/ov-new1.7.html
Testcase (WinXP SP2 and 3, Cygwin 1.7.0-60):
$ touch foo
$
On Aug 26 20:37, Christian Franke wrote:
> If ACLs are used, Cygwin 1.7 chmod() does never set R/O attribute, but
> open() sets it if a R/O file is created:
> [...]
> This change might be enough (or not):
>
> fhandler_base::open (int flags, mode_t mode)
> ...
> -if (!(mode & (S_IWUSR | S_IWG
If ACLs are used, Cygwin 1.7 chmod() does never set R/O attribute, but
open() sets it if a R/O file is created:
$ touch test1
$ chmod a=r test1
$ cp -p test1 test2
$ ls -l test1 test2
-r--r--r-- 1 franke users 0 Aug 26 19:33 test1
-r--r--r-- 1 franke users 0 Aug 26 19:33 test2
$ attrib 'test
2009/8/11 Corinna Vinschen:
> On Aug 11 12:44, Reini Urban wrote:
>> 2009/8/11 Corinna Vinschen:
>> > That might be a good workaround nevertheless. You should just test the
>> > list of supplementary groups as well, along these lines:
>>
>> We already have an ingroup() check in this Perl_cando() f
On Aug 11 12:44, Reini Urban wrote:
> 2009/8/11 Corinna Vinschen:
> > That might be a good workaround nevertheless. You should just test the
> > list of supplementary groups as well, along these lines:
>
> We already have an ingroup() check in this Perl_cando() function, so
> there is no
> need t
2009/8/11 Corinna Vinschen:
> On Aug 11 04:49, Reini Urban wrote:
>> 2009/8/11 Reini Urban:
>> > 2009/8/10 Corinna Vinschen:
>> >> On Aug 10 20:11, Alexey Borzenkov wrote:
>> >>> Anyway, it means there is a bug in perl, because on Linux:
>> >>>
>> >>> r...@kitsu:~# touch test.txt
>> >>> r...@kitsu:
On Aug 11 04:49, Reini Urban wrote:
> 2009/8/11 Reini Urban:
> > 2009/8/10 Corinna Vinschen:
> >> On Aug 10 20:11, Alexey Borzenkov wrote:
> >>> Anyway, it means there is a bug in perl, because on Linux:
> >>>
> >>> r...@kitsu:~# touch test.txt
> >>> r...@kitsu:~# chmod 0444 test.txt
> >>> r...@kit
2009/8/11 Reini Urban:
> 2009/8/10 Corinna Vinschen:
>> On Aug 10 20:11, Alexey Borzenkov wrote:
>>> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
>>> Vinschen wrote:
>>> > That's a bug in your testsuite. I assume you're running the tests as
>>> > administrator, right? Administrators have the right to
2009/8/10 Corinna Vinschen:
> On Aug 10 20:11, Alexey Borzenkov wrote:
>> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
>> Vinschen wrote:
>> > That's a bug in your testsuite. I assume you're running the tests as
>> > administrator, right? Administrators have the right to write to all
>> > files, even
Alexey Borzenkov wrote:
> On Mon, Aug 10, 2009 at 8:11 PM, Alexey Borzenkov wrote:
>> Anyway, it means there is a bug in perl, because on Linux:
>
> On second though, it is actually bug in Cygwin. Programs and libraries expect
> superuser behavior only when user id is zero, which is clearly not th
On Mon, Aug 10, 2009 at 8:40 PM, Corinna
Vinschen wrote:
> That's a bug in perl. There are other OSes out there which have
> root-like permissions for non-0 uids. Perl should use the access()
> function to check for read/write/execute permissions, which always
> returns the correct result indepen
On Mon, Aug 10, 2009 at 8:11 PM, Alexey Borzenkov wrote:
> Anyway, it means there is a bug in perl, because on Linux:
On second though, it is actually bug in Cygwin. Programs and libraries
expect superuser behavior only when user id is zero, which is clearly
not the case in Cygwin 1.7. I think tha
On Aug 10 20:11, Alexey Borzenkov wrote:
> On Mon, Aug 10, 2009 at 5:25 PM, Corinna
> Vinschen wrote:
> > That's a bug in your testsuite. I assume you're running the tests as
> > administrator, right? Administrators have the right to write to all
> > files, even R/O files, according to POSIX rule
On Mon, Aug 10, 2009 at 5:25 PM, Corinna
Vinschen wrote:
> That's a bug in your testsuite. I assume you're running the tests as
> administrator, right? Administrators have the right to write to all
> files, even R/O files, according to POSIX rules. Your test would fail
> on Linux as well, if you
On Aug 10 17:19, Alexey Borzenkov wrote:
> Hi,
>
> $ echo foo >test.txt
> $ chmod 0444 test.txt
> $ echo bar >test.txt
>
> This succeeds, even though the file is readonly, and permissions don't
> allow writing to the file. What's even stranger is that
Hi,
$ echo foo >test.txt
$ chmod 0444 test.txt
$ echo bar >test.txt
This succeeds, even though the file is readonly, and permissions don't
allow writing to the file. What's even stranger is that other programs
(i.e. Notepad and other editors) can't write to this file,
On Jan 1 04:52, Michael Bax wrote:
> When attempting to edit a *writeable* file of "zero" lines but 53 MB in size
> (no newlines), vi appears to hang.
But it doesn't. It just needs a lot of time to process the file.
After all vim is an editor. It searches the whole file for line-endings
etc. T
When attempting to edit a *writeable* file of "zero" lines but 53 MB in size
(no newlines), vi appears to hang. Ctrl-C is followed by the response
W10: Warning: Changing a readonly file
following which it appears that one is editing a new file. Quitting without
writin
* Martin Gainty (2004-03-16 16:24 +0100)
> If you
> chmod 511 /bin/bash.exe and run
> bash.exe
> you will encounter same capabilities as executing
> bash.exe --restricted
Nonsense.
> There is a correlation between the 2 operations but I'm smart enough to say
> I don't understand what the bash bin
tin Gainty
- Original Message -
From: "Igor Pechtchanski" <[EMAIL PROTECTED]>
To: "Martin Gainty" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, March 16, 2004 10:15 AM
Subject: Re: Readonly
> Huh? My "solution" just makes the bash e
t; - Original Message -
> From: "Igor Pechtchanski" csnyuedu>
> To: "Martin Gainty" hotmailcom>
> Cc: cygwincom>
> Sent: Tuesday, March 16, 2004 9:18 AM
> Subject: Re: Readonly
>
>
> > On Tue, 16 Mar 2004, Martin Gainty wrote:
>
Sent: Tuesday, March 16, 2004 9:18 AM
Subject: Re: Readonly
> On Tue, 16 Mar 2004, Martin Gainty wrote:
>
> > Folks
> > How do I setup Cygwin BASH for Readonly mode?
> > Many Thanks,
> > Martin Gainty
>
> "chmod 511 /bin/bash". :-)
>
> If tha
On Tue, 16 Mar 2004, Martin Gainty wrote:
> Folks
> How do I setup Cygwin BASH for Readonly mode?
> Many Thanks,
> Martin Gainty
"chmod 511 /bin/bash". :-)
If that's not what you meant, you'll need to state your question more
clearly. Try re-reading
Folks
How do I setup Cygwin BASH for Readonly mode?
Many Thanks,
Martin Gainty
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com
48 matches
Mail list logo
