> A robust solution which also reduces syscalls does not necessarily
> require a precise answer here.
>
> I suggest writing a wrapper function which has on the stack
> CSTR sidbuf[SECURITY_MAX_SID_SIZE];
> and calls LookupAccountNameA() passing sidbuf as Sid.
> If it succeeds, then malloc() retu
)| to find out which
> > > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > > should I use) ?
> > > >
> > > > PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > > [snip]
> > >
> >
lass|
> > > > > > should I use) ?
> > > > >
> > > > > PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > > > [snip]
> > > >
> > > > Win32/NT API question: All known SIDs will fit into
> > > > |SECUR
rrentThreadToken(), ...)| to find out which
> > > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > > should I use) ?
> > > >
> > > > PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > > [snip]
>
|TokenInformationClass|
> > > > should I use) ?
> > >
> > > PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > [snip]
> >
> > Win32/NT API question: All known SIDs will fit into
> > |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right no
ITY_MAX_SID_SIZE);
> [snip]
>
> Win32/NT API question: All known SIDs will fit into
> |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
> the ms-nfs41-client code assumes that all SIDs use a variable amount
> of memory, and we always have to ask the Win32/NT API about
), ...)| to find out which
> > group is the new "current group" (e.g. which |TokenInformationClass|
> > should I use) ?
>
> PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
[snip]
Win32/NT API question: All known SIDs will fit into
|SECURITY_MAX_SID_SIZE| bytes, ri
dev/null
The authenticity of host 'localhost (::1)' can't be established.
ED25519 key fingerprint is SHA256:rK/5qL4K+LBmYS2LfQQH1dT4fmB7+Oi7YlWLTDJvPRU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanentl
On 2023-06-24 00:12, Kevin Schnitzius wrote:
On Friday, June 23, 2023 at 10:00:02 PM EDT, Chris Roehrig via Cygwin
wrote:
Thanks. There must be some issue with my setup. Very odd that 'pv'
works, but 'cat' does not. ldd shows they use identical libs. I guess
I'll start with the pv a
On 2023-06-23 22:35, Brian Inglis wrote:
On 2023-06-23 20:19, Dan Harkless via Cygwin wrote:
Before you resort to trawling through source, did you try a fresh
Cygwin install (either to a different directory, or after temporarily
moving your current tree)? Sometimes, e.g. if you use the same
On Friday, June 23, 2023 at 10:00:02 PM EDT, Chris Roehrig via Cygwin
wrote:
> Thanks. There must be some issue with my setup. Very odd that 'pv'
> works, but 'cat' does not. ldd shows they use identical libs. I guess
> I'll start with the pv and cat source.
Try this first:
/usr/bin/d
On 6/23/2023 10:35 PM, Brian Inglis wrote:
On 2023-06-23 20:19, Dan Harkless via Cygwin wrote:
> Before you resort to trawling through source, did you try a fresh Cygwin install
> (either to a different directory, or after temporarily moving your current
> tree)? Sometimes, e.g. if you use the
On 2023-06-23 20:19, Dan Harkless via Cygwin wrote:
On 6/23/2023 6:59 PM, Chris Roehrig via Cygwin wrote:
On 2023-06-23 18:26, Dan Harkless via Cygwin wrote:
On 6/23/2023 5:19 PM, Chris Roehrig via Cygwin wrote:
Yes, with all Cygwin64 updates, I was able to scp a file of a few MB
from Linux to
On 6/23/2023 6:59 PM, Chris Roehrig via Cygwin wrote:
On 2023-06-23 18:26, Dan Harkless via Cygwin wrote:
> On 6/23/2023 5:19 PM, Chris Roehrig via Cygwin wrote:
> Yes, with all Cygwin64 updates, I was able to scp a file of a few MB
> from Linux to Windows 10 with no issues. I also tried your '
On 2023-06-23 18:26, Dan Harkless via Cygwin wrote:
On 6/23/2023 5:19 PM, Chris Roehrig via Cygwin wrote:
No worries; I imagine most people don't run sshd on cygwin.
Hmm, I'd generally think the opposite, at least for users coming from
more UNIXey / Linuxey backgrounds.
It looks to
me li
On 6/23/2023 5:19 PM, Chris Roehrig via Cygwin wrote:
No worries; I imagine most people don't run sshd on cygwin.
Hmm, I'd generally think the opposite, at least for users coming from
more UNIXey / Linuxey backgrounds.
It looks to
me like the issue involves i/o between sshd and its sub-proc
06-23 16:27, Voris, Ben wrote:
I did not and cannot. Sorry.
Fwiw, pushing from Cygwin to the remote also worked.
-Original Message-
From: Chris Roehrig
Sent: 23 June 2023 17:23
To: Voris, Ben
Subject: Re: scp and ssh 'cat' stalls at 64k bytes
Did you execute the scp on the
Re: scp and ssh 'cat' stalls at 64k bytes
>
>
> On 2023-06-23 08:28, Brian Inglis wrote:
> > On 2023-06-23 00:26, Chris Roehrig via Cygwin wrote:
> >> I've upgraded cygwin recently (from a much older version) and am
> >> encountering a new proble
On 2023-06-23 08:28, Brian Inglis wrote:
On 2023-06-23 00:26, Chris Roehrig via Cygwin wrote:
I've upgraded cygwin recently (from a much older version) and am
encountering a new problem on all my Win10/WIn11 machines.
With openssh and pv installed on cygwin (3.4.7-1):
dd if=/dev/zero bs=1 co
On 2023-06-23 00:26, Chris Roehrig via Cygwin wrote:
I've upgraded cygwin recently (from a much older version) and am encountering a
new problem on all my Win10/WIn11 machines.
With openssh and pv installed on cygwin (3.4.7-1):
dd if=/dev/zero bs=1 count=65536 | ssh localhost 'cat > /dev/null'
I've upgraded cygwin recently (from a much older version) and am
encountering a new problem on all my Win10/WIn11 machines.
With openssh and pv installed on cygwin (3.4.7-1):
dd if=/dev/zero bs=1 count=65536 | ssh localhost 'cat > /dev/null' #
works
dd if=/dev/zero bs=1 count=65537 | ssh lo
On Wed, 30 Mar 2022 05:08:09 +0200
john p wrote:
> to reproduce:
>
> emacs -Q -nw
> C-x C-f /-::
>
> stackdump & gdb backtrace attached
>
> problem only seen with:
> emacs-27.2-1 windows7 cygwin-3.3.4-2
>
> problem doesnt happen with:
> emacs-27.2-1 windows7 cygwin-3.3.3-1
> emacs-2
to reproduce:
emacs -Q -nw
C-x C-f /-::
stackdump & gdb backtrace attached
problem only seen with:
emacs-27.2-1 windows7 cygwin-3.3.4-2
problem doesnt happen with:
emacs-27.2-1 windows7 cygwin-3.3.3-1
emacs-27.2-1 windows10 cygwin-3.3.4-2
hopefully someone knows significance of 102
Hello,
I have been using cygwin as my local PHP development suite, and for some
time now, PHP has been crashing on files that are a multiple of 4k in
size. Just run this in your terminal to observe the crash:
kbs1@DESKTOP-QR0EO0L /cygdrive/c/Users/kbs1/Desktop
$ if [ -f test.php ]; then rm test.p
reams, but this calls lseek, not fflush.
Looks like a patch is required. Stay tuned.
is it though? he says "write 65536 + 1 bytes", but as far as i can
tell, you
cant do that. quoting myself:
Seeking, reading and writing must all be done in multiples of sector
size, in
my case 5
On Tue, Dec 19, 2017 at 6:19 PM, Corinna Vinschen
wrote:
> On Dec 19 16:35, Ivan Kozik wrote:
>> From what I observe on Linux, it supports writing at any offset to the
>> block device because it does a read-modify-write behind the scenes,
>> with accompanying nasty overhead (e.g. writes going at 6
On Dec 19 16:35, Ivan Kozik wrote:
> On Tue, Dec 19, 2017 at 4:13 PM, Eric Blake wrote:
> > Can block devices report an unaligned offset to lseek()? If not, then when
> > writing an unaligned value to a block device, don't we have to do a
> > read-modify-write of the larger aligned cluster, and t
On Tue, Dec 19, 2017 at 4:13 PM, Eric Blake wrote:
> Can block devices report an unaligned offset to lseek()? If not, then when
> writing an unaligned value to a block device, don't we have to do a
> read-modify-write of the larger aligned cluster, and then put lseek() back
> to the unaligned bou
On 12/19/2017 09:46 AM, Ivan Kozik wrote:
Thanks, I can confirm that the 2017-12-18 snapshot fixed the test
program I posted.
What about the harder case where the program calls fflush, though?
#include
int main(int argc, char *argv[]) {
FILE *f = fopen(argv[1], "w");
char x[65536 +
t; the stdio buffer:
>
> fwrite(65537)
> -> write(65536)
> -> store 1 byte in FILE._buf
>
> ftell calls lseek which returns 65536. It adds the number of bytes
> still in the buffer, so it should return 65537. Further fwrite's
> seemlessly append to the bytes
sh in this case. There's only a special case for
> > appending streams, but this calls lseek, not fflush.
> >
> > Looks like a patch is required. Stay tuned.
>
> is it though? he says "write 65536 + 1 bytes", but as far as i can tell, you
> cant do tha
Looks like a patch is required. Stay tuned.
is it though? he says "write 65536 + 1 bytes", but as far as i can tell, you
cant do that. quoting myself:
Seeking, reading and writing must all be done in multiples of sector size, in
my case 512 bytes
http://web.archive.org/web/st
On Dec 16 02:07, Ivan Kozik wrote:
> Hello,
>
> I have discovered that if you write 65536 + 1 bytes to a block device
> in cygwin, the file position can become 65536 + 512.
>
> With /dev/sdc as a throwaway USB block device:
>
> (cygwin_write.c is pasted below)
> # gc
Hello,
I have discovered that if you write 65536 + 1 bytes to a block device
in cygwin, the file position can become 65536 + 512.
With /dev/sdc as a throwaway USB block device:
(cygwin_write.c is pasted below)
# gcc -O2 -Wall -o cygwin_write cygwin_write.c
# ./cygwin_write /dev/sdc
66048
I am
n/fhandler.cc;h=6f024da3288053359de36baf41fa095819d252cc;hb=HEAD#l1944
I'm now trying to reproduce this again, but I'm really not sure
where to look and, as I wrote, last time I was unable to reproduce
this despite running the testcase for hours.
It might be interesting to see if there
1 94796 | sed -re "s/.*/B0&-N01/g")
. > B014569-N01
.B094793-N01<
... Searching that block number in the produced scp/ssh-trace (the code for the
other log-printouts is given in the referenced old thread) shows that the data
of the 16k block
On Mar 2 20:03, Takashi Yano wrote:
> Thank you, Corinna.
>
> On Sat, 28 Feb 2015 14:47:48 +0100
> Corinna Vinschen wrote:
>
> > Thanks, but right now we are lacking a maintainer for the inetutils
> > package. Is maintainance for a Cygwin package something you might be
> > interest in? If so,
Thank you, Corinna.
On Sat, 28 Feb 2015 14:47:48 +0100
Corinna Vinschen wrote:
> Thanks, but right now we are lacking a maintainer for the inetutils
> package. Is maintainance for a Cygwin package something you might be
> interest in? If so, have a look at
>
> https://sourceware.org/cygwin/
On Feb 28 14:28, Takashi Yano wrote:
> Package: inetutils-server
> Version: 1.9.1-2 or older
>
> Telnetd in inetutils-server package lacks handling of some of
> TIOCPKT control bytes. The most influential thing is a lack of
> handling of TIOCPKT_DATA. TIOCPKT_DATAs i.e. '\
Package: inetutils-server
Version: 1.9.1-2 or older
Telnetd in inetutils-server package lacks handling of some of
TIOCPKT control bytes. The most influential thing is a lack of
handling of TIOCPKT_DATA. TIOCPKT_DATAs i.e. '\0's frequently
appear in the stream of network side.
In most
, at least not an easy one for
Cygwin. The problem is that the dirent structure has no room for a
multibyte string of more than 255 bytes, while the underlying OS
provides filenames with up to 255 UTF-16 chars.
To support that, we would have to raise the size of a single dirent so
that it allows
Hi,
I'm using Cygwin 1.7.7 in UTF-8 mode. I have a file whose name is composed of
Hebrew character, so the UTF-8 representation is longer than 255 characters.
Trying "ls -l" fails to list the file's attributes.
Using a short C program that loops through a directory (readdir()/stat()) shows
that r
shows a total number of 398 460 132 sectors for
partition sdd1, based on 512 bytes/sector , giving a total of 204 011
587 584 bytes.
Which version of cygwin? There have been patches in this area for cygwin 1.7.
- --
Don't work too hard, make some time for fun as well!
Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to egghe...@gmx.net on 7/4/2009 2:10 AM:
> My partition table shows a total number of 398 460 132 sectors for
> partition sdd1, based on 512 bytes/sector , giving a total of 204 011
> 587 584 bytes.
Which version of cygwin? T
My partition table shows a total number of 398 460 132 sectors for
partition sdd1, based on 512 bytes/sector , giving a total of 204 011
587 584 bytes.
dd states 2048 bytes less:
dd if=/dev/sdd1 of=/dev/st0 bs=4096k
48460+1 records in
48460+1 records out
204 011 585 536 bytes (204 GB) copied
h I've
> done on two cygwin installations), or from the twisted buildbot --
> http://buildbot.twistedmatrix.com/builders/cygwin-py2.5-select -- then once
> the child process closes its fd #2, it subsequently receives no further
> bytes from its fd #1, even though the parent process has
wisted buildbot -- http://buildbot.twistedmatrix.com/
builders/cygwin-py2.5-select -- then once the child process closes
its fd #2, it subsequently receives no further bytes from its fd #1,
even though the parent process has written some bytes to that pipe.
I can reproduce this by running the Twi
quot;ESLF" (printed in hex bytes):
>
> 54 39 CA 1A 44
0x1a (ctrl-z) in a text file is Windows EOF. Read binary data in binary
mode if you want all the bytes.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Ver
"could not open ESLF file" << endl;
::exit( 1 );
}
char buf[ 64 ];
ssize_t bytesRead = ::read( fd, buf, sizeof( buf ) );
cout << "read " << bytesRead << " bytes" << endl;
ot open ESLF file" << endl;
::exit( 1 );
}
char buf[ 64 ];
ssize_t bytesRead = ::read( fd, buf, sizeof( buf ) );
cout << "read " << bytesRead << " bytes" << endl;
::close( fd
fer, the idea of my program is the following: Put
>the RTS signal low, write some bytes, wait until everything is transmitted
>and then raise again the RTS signal...
I didn't say you were reading any buffer. Most modern serial devices
contain buffers so when you send a byte to a com devi
you're just seeing the effects of a buffer on the comm
>device itself not draining even though Windows has flushed everything
>from its own memory.
I'm not reading any buffer, the idea of my program is the following: Put
the RTS signal low, write some bytes, wait until everything i
On Mon, May 16, 2005 at 10:22:00AM +0100, [EMAIL PROTECTED] wrote:
>I'm trying to use the serial port with Cygwin, and here is my problem:
>
>I can successfully write on the line, but I need to switch the RTS and DTR
>lines just AFTER the last byte is written in the line. I put
Hi,
I'm trying to use the serial port with Cygwin, and here is my problem:
I can successfully write on the line, but I need to switch the RTS and DTR
lines just AFTER the last byte is written in the line. I put the bytes that
I want in the line with the command Write and I wait for the
On Dec 14 21:00, David wrote:
> This is the actual print
>
> drive type : 27 (DLT compact tape))
> tape capacity: 39758848 KB remaining: 39909992 KB
> current file :0 active partition :0
> current block:0 cur
This is the actual print
drive type : 27 (DLT compact tape))
tape capacity: 39758848 KB remaining: 39909992 KB
current file :0 active partition :0
current block:0 cur logical block:0
General status bit
On Dec 13 22:49, David wrote:
> Yes. the "mt satus 2" is telling me that 128 bytes is the maximum
Hey, not so many details at once. Some pasting of the output would
have been nice. If `mt status 2' prints 128 then that's what the
Windows driver reports in a call to GetTap
Yes. the "mt satus 2" is telling me that 128 bytes is the maximum
Corinna Vinschen cygwin.com> writes:
>
> On Dec 13 17:49, David wrote:
> > For some reason my DLT 8000 drive is telling Cygwin (or vise versa) that
the
> > maximum blocking factor it can write t
And if you were to boot into something like Knoppix, does
it report the same value?
On Mon, 13 Dec 2004 22:49:13 + (UTC), David wrote:
>Yes. the "mt satus 2" is telling me that 128 bytes is the maximum
>Corinna Vinschen cygwin.com> writes:
>>
>> On Dec
On Dec 13 17:49, David wrote:
> For some reason my DLT 8000 drive is telling Cygwin (or vise versa) that the
> maximum blocking factor it can write to DLT is 128.
Is that what `mt status 2' prints?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Proje
For some reason my DLT 8000 drive is telling Cygwin (or vise versa) that the
maximum blocking factor it can write to DLT is 128. Windows allows it to write
the blocking factor to 512bytes. Any idea how to change that?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem re
> Cygwin cannot handle files larger than ~2GB.
>
mmm...
> > Is Cygwin able to handle Large Files??, Any idea?
>
> There is work going on at the moment to migrate Cygwin's system calls
> 64-bit. To read-up on what's already happend take a look at the
> cygwin-patches/cygwin-developers mailing lis
> Hello,
>
> I can't transfer big files. In the output below, you can see that rsync
only
> transfer 1383275520 of a 5448046592 bytes file:
Cygwin cannot handle files larger than ~2GB.
> Is Cygwin able to handle Large Files??, Any idea?
There is work going on at the moment
Rsync - Can't transfer files bigger than 1383275520 bytes
Hello,
I can't transfer big files. In the output below, you can see that rsync only
transfer 1383275520 of a 5448046592 bytes file:
F:\shells>rsync -e ssh -avz ./backup [EMAIL PROTECTED]:backups
[EMAIL PROTECTED]'s passw
Hello,
I can't transfer big files. In the output below, you can see that rsync only
transfer 1383275520 of a 5448046592 bytes file:
F:\shells>rsync -e ssh -avz ./backup [EMAIL PROTECTED]:backups
[EMAIL PROTECTED]'s password:
building file list ... done
wrote 114 bytes read 20 byte
programming practices...
Randall Schulz
At 08:53 2003-02-25, Emilio Hernandez-Garcia wrote:
Hi all,
This code is supposed to use 'write' to write in binary format a float
array of 12
elements (thus 4*12=48 bytes) to stdout (on execution it is redirected
to a file):
/*
Hi all,
This code is supposed to use 'write' to write in binary format a float
array of 12
elements (thus 4*12=48 bytes) to stdout (on execution it is redirected
to a file):
/* * */
#include
main() {
float const vector[12]={1.,0.2,2.,0.,1.,-1
aa.data
> touch .data
> ls *.data
> bash: /usr/bin/ls: Invalid argument
> # everything Breaks Down
>
>
> On my Directory the length of all the filenames is 96707 bytes or
>\x179C3 if you
On my Directory the length of all the filenames is 96707 bytes or
\x179C3 if you add one more char as explained before it will fail.
I have the latest release Cygwin as of this posting. PC with Windows
2000 SP3 :-( with 256 Meg of Ram (Plenty left for malloc). The Cygperf is
also included i
69 matches
Mail list logo
