Really appreaciate the recommendation that Dave Korn suggested. We went
ahead and modified the cygwin1.dll for version 1.5.19-4, which is the
one we have installed for testing. In the event of checking out our
change we found a bug in the current SCSI device handling of major
number 65, i.e. any
Thanks for the feedback Dave.
Is there a solution to getting more devices mapped without modifying the
Cygwin source? We test with Cygwin using distributed components only.
We do develop our own test components under Cygwin, so a programmatic
recommendation is acceptable.
Mapping something lik
We are currently using Cygwin to test an iSCSI based storage subsystem.
Recently we are discussing about a test that will be connecting to 32
iSCSI volumes, effectively creating a total of 33 (32 + 1 direct
attached disk) harddisk references in Windows. In reviewing the current
POSIX mapping, we
Can anyone tell us what Windows error status gets mapped as ENOENT
return status for wite() or read() system calls? We have a test program
that runs for hours, sometimes days doing constant I/O to an iSCSI
volume and sporadically we will get an ENOENT return status from either
the write() or read
(3,
0x10EED60, 1), errno 0
Thanks,
Joe
-Original Message-
From: Corinna Vinschen [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 08, 2005 4:57 AM
To: cygwin@cygwin.com
Subject: Re: Error reported dd'ing close of end of block device with
skip
On Dec 7 19:35, Corinna Vinschen
> This should be fixed now, too, in CVS. Please try the next developers
snapshot.
We just downloaded cygwin-inst-20051213.tar.bz2 and tried the snapshot.
Problem with lseek(SEEK_END) is resolve and the result returned
corresponded with the /proc/partitions.
Thank you.
Joe
--
Unsubscribe info:
>> On Dec 7 11:17, Loh, Joe wrote:
>> We just installed the cygwin-inst-20051207.tar.bz2 snapshot. The
>> output in //proc/partitions is the same as the Cygwin Kernel 1.5.18.
>> However, the lseek(SEEK_END) no longer works. When I rerun the "C"
>> pro
>> On Dec 7 11:55, Loh, Joe wrote:
>> QUESTION:
>>
>> Is there a way in Cygwin to do a read of a block device using "C"
that
>> does not do a read-ahead? We needed to develop an application that
>> will issue the exact transfer size to the
> Searching the archive
>
> http://cygwin.com/cgi-bin/htsearch?config=htdig&words=dd+eom
>
> reveals a thread "Bug in dd ?? at EOM" which starts here:
>
> http://sourceware.org/ml/cygwin/2005-09/msg00878.html
>
> Btw, have you tried the latest snapshot from
http://cygwin.com/snapshots/ ?
>
>
> C
> Have you tried this with the latest snashot from
http://cygwin.com/snapshots ?
>
>
> Corinna
We just installed the cygwin-inst-20051207.tar.bz2 snapshot. The output
in //proc/partitions is the same as the Cygwin Kernel 1.5.18. However,
the lseek(SEEK_END) no longer works. When I rerun the "C"
Hello folks,
We have created the following test case to illustrate the behavior that
we observed. Hopefully someone out there can shed some light into the
subject matter.This behavior is observed running "CYGWIN_NT-5.2
P3PANDA 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin".
T
Folks,
Since updating the Cygwin 1.5.18, we started seeing problem similar to
the what "dd" is experiencing. The previous Cygwin DLL we used was
Cygwin 1.5.16, at that works flawlessly. Is anyone out there
experiencing the same issue?
I have reverted back to the Cygwin 1.5.16 and everything star
Hello all,
I have not been able to find anything in cygwin implying that the read()
function call or 'dd' can read a "raw" disk pass the 1 terabyte limit.
I get similar result as 'dd' when using the read() function call; the
lseek()function call appears to work fine SEEK_SET beyond 1 terabyte
limit
13 matches
Mail list logo
