* Re: BUG: open() O_ flags one bit too high
@ 1999-09-05 3:00 Victor Szel
1999-09-05 3:33 ` John R Hanson
1999-09-30 23:42 ` Victor Szel
0 siblings, 2 replies; 20+ messages in thread
From: Victor Szel @ 1999-09-05 3:00 UTC (permalink / raw)
To: cygwin
Chris,
> > >#ifdef __CYGWIN__
> > >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
> > >static inline int FixCygwinIOflags( int flags )
> > >{
> > > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
> > > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
> > >}
> > >#endif
> >
> > System O_CREAT (octal) O_CREAT (hex)
> > ----------------------------------------------------
> > Cygwin 01000 0x200
> > Digital UNIX 01000 0x200
> > FreeBSD 01000 0x200
> > Irix 00400 0x100
> > Linux 00100 0x040
> > SCO UNIX 3.2 00400 0x100
> > Solaris 00400 0x100
> > Ultrix 01000 0x200
> >
> > What was the bug again?
>
> It could be that it's some sort of feature/bug in WinNT and not in Cygwin then,
> since the O_CREAT flag passed to open() was 0x200, but open always
> returned -1 in this case. WinNT 4.0 SP5 and Win2000 Build 2072 is the
> same in this respect. If this is the case, a workaround in Cygwin could be
> worth considering.
After digging a bit more here's a snippet from
the FCNTL.H supplied with MS VC++ 4:
#define _O_CREAT 0x0100 /* create and open file */
#define _O_TRUNC 0x0200 /* open and truncate */
#define _O_EXCL 0x0400 /* open only if file doesn't already exist */
#define O_CREAT _O_CREAT
#define O_TRUNC _O_TRUNC
#define O_EXCL _O_EXCL
Victor Szel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 3:00 BUG: open() O_ flags one bit too high Victor Szel
@ 1999-09-05 3:33 ` John R Hanson
[not found] ` <013701bef7a0$92bd7370$0a0ac8c8@VECWS1>
1999-09-30 23:42 ` John R Hanson
1999-09-30 23:42 ` Victor Szel
1 sibling, 2 replies; 20+ messages in thread
From: John R Hanson @ 1999-09-05 3:33 UTC (permalink / raw)
To: Victor Szel; +Cc: cygwin
Cygwin uses win32 calls, not crtdll or msvcrt(XX)
calls, so the only way you can tell which flags
do what is to USE THE SOURCE LUKE ;-)
if you have had problems with open, you may
be using the wrong headers, DO NOT use vc++
or mingw32 headers when building cygwin apps.
On Sun, 5 Sep 1999 12:00:26 +0200, you wrote:
>Chris,
>
>> > >#ifdef __CYGWIN__
>> > >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
>> > >static inline int FixCygwinIOflags( int flags )
>> > >{
>> > > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
>> > > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
>> > >}
>> > >#endif
>> >
>> > System O_CREAT (octal) O_CREAT (hex)
>> > ----------------------------------------------------
>> > Cygwin 01000 0x200
>> > Digital UNIX 01000 0x200
>> > FreeBSD 01000 0x200
>> > Irix 00400 0x100
>> > Linux 00100 0x040
>> > SCO UNIX 3.2 00400 0x100
>> > Solaris 00400 0x100
>> > Ultrix 01000 0x200
>> >
>> > What was the bug again?
>>
>> It could be that it's some sort of feature/bug in WinNT and not in Cygwin then,
>> since the O_CREAT flag passed to open() was 0x200, but open always
>> returned -1 in this case. WinNT 4.0 SP5 and Win2000 Build 2072 is the
>> same in this respect. If this is the case, a workaround in Cygwin could be
>> worth considering.
>
>After digging a bit more here's a snippet from
>the FCNTL.H supplied with MS VC++ 4:
>
>#define _O_CREAT 0x0100 /* create and open file */
>#define _O_TRUNC 0x0200 /* open and truncate */
>#define _O_EXCL 0x0400 /* open only if file doesn't already exist */
>
>#define O_CREAT _O_CREAT
>#define O_TRUNC _O_TRUNC
>#define O_EXCL _O_EXCL
>
>Victor Szel
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
[not found] ` <013701bef7a0$92bd7370$0a0ac8c8@VECWS1>
@ 1999-09-05 22:46 ` John R Hanson
1999-09-30 23:42 ` John R Hanson
0 siblings, 1 reply; 20+ messages in thread
From: John R Hanson @ 1999-09-05 22:46 UTC (permalink / raw)
To: Victor Szel, cygwin
You cannot use ANYTHING compiled for
mingw32 when linking cygwin apps.
libmoldname contains pointers to functions
in crtdll, use objdump -p to see what dll's
and functions you are linking to.
On Sun, 5 Sep 1999 15:14:22 +0200, you wrote:
>John,
>
>
>> Cygwin uses win32 calls, not crtdll or msvcrt(XX)
>> calls, so the only way you can tell which flags
>> do what is to USE THE SOURCE LUKE ;-)
>> if you have had problems with open, you may
>> be using the wrong headers, DO NOT use vc++
>> or mingw32 headers when building cygwin apps.
>
>The headers are OK, I've checked them: #include <fcntl.h>,
>and this points to the Cygwin fcntl.h.
>
>But:
>
>We are linking Harbour with the MOLDNAME library, could
>this be the problem ?
>
>Victor Szel
>
>
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 3:00 BUG: open() O_ flags one bit too high Victor Szel
1999-09-05 3:33 ` John R Hanson
@ 1999-09-30 23:42 ` Victor Szel
1 sibling, 0 replies; 20+ messages in thread
From: Victor Szel @ 1999-09-30 23:42 UTC (permalink / raw)
To: cygwin
Chris,
> > >#ifdef __CYGWIN__
> > >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
> > >static inline int FixCygwinIOflags( int flags )
> > >{
> > > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
> > > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
> > >}
> > >#endif
> >
> > System O_CREAT (octal) O_CREAT (hex)
> > ----------------------------------------------------
> > Cygwin 01000 0x200
> > Digital UNIX 01000 0x200
> > FreeBSD 01000 0x200
> > Irix 00400 0x100
> > Linux 00100 0x040
> > SCO UNIX 3.2 00400 0x100
> > Solaris 00400 0x100
> > Ultrix 01000 0x200
> >
> > What was the bug again?
>
> It could be that it's some sort of feature/bug in WinNT and not in Cygwin then,
> since the O_CREAT flag passed to open() was 0x200, but open always
> returned -1 in this case. WinNT 4.0 SP5 and Win2000 Build 2072 is the
> same in this respect. If this is the case, a workaround in Cygwin could be
> worth considering.
After digging a bit more here's a snippet from
the FCNTL.H supplied with MS VC++ 4:
#define _O_CREAT 0x0100 /* create and open file */
#define _O_TRUNC 0x0200 /* open and truncate */
#define _O_EXCL 0x0400 /* open only if file doesn't already exist */
#define O_CREAT _O_CREAT
#define O_TRUNC _O_TRUNC
#define O_EXCL _O_EXCL
Victor Szel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 3:33 ` John R Hanson
[not found] ` <013701bef7a0$92bd7370$0a0ac8c8@VECWS1>
@ 1999-09-30 23:42 ` John R Hanson
1 sibling, 0 replies; 20+ messages in thread
From: John R Hanson @ 1999-09-30 23:42 UTC (permalink / raw)
To: Victor Szel; +Cc: cygwin
Cygwin uses win32 calls, not crtdll or msvcrt(XX)
calls, so the only way you can tell which flags
do what is to USE THE SOURCE LUKE ;-)
if you have had problems with open, you may
be using the wrong headers, DO NOT use vc++
or mingw32 headers when building cygwin apps.
On Sun, 5 Sep 1999 12:00:26 +0200, you wrote:
>Chris,
>
>> > >#ifdef __CYGWIN__
>> > >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
>> > >static inline int FixCygwinIOflags( int flags )
>> > >{
>> > > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
>> > > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
>> > >}
>> > >#endif
>> >
>> > System O_CREAT (octal) O_CREAT (hex)
>> > ----------------------------------------------------
>> > Cygwin 01000 0x200
>> > Digital UNIX 01000 0x200
>> > FreeBSD 01000 0x200
>> > Irix 00400 0x100
>> > Linux 00100 0x040
>> > SCO UNIX 3.2 00400 0x100
>> > Solaris 00400 0x100
>> > Ultrix 01000 0x200
>> >
>> > What was the bug again?
>>
>> It could be that it's some sort of feature/bug in WinNT and not in Cygwin then,
>> since the O_CREAT flag passed to open() was 0x200, but open always
>> returned -1 in this case. WinNT 4.0 SP5 and Win2000 Build 2072 is the
>> same in this respect. If this is the case, a workaround in Cygwin could be
>> worth considering.
>
>After digging a bit more here's a snippet from
>the FCNTL.H supplied with MS VC++ 4:
>
>#define _O_CREAT 0x0100 /* create and open file */
>#define _O_TRUNC 0x0200 /* open and truncate */
>#define _O_EXCL 0x0400 /* open only if file doesn't already exist */
>
>#define O_CREAT _O_CREAT
>#define O_TRUNC _O_TRUNC
>#define O_EXCL _O_EXCL
>
>Victor Szel
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 22:46 ` John R Hanson
@ 1999-09-30 23:42 ` John R Hanson
0 siblings, 0 replies; 20+ messages in thread
From: John R Hanson @ 1999-09-30 23:42 UTC (permalink / raw)
To: Victor Szel, cygwin
You cannot use ANYTHING compiled for
mingw32 when linking cygwin apps.
libmoldname contains pointers to functions
in crtdll, use objdump -p to see what dll's
and functions you are linking to.
On Sun, 5 Sep 1999 15:14:22 +0200, you wrote:
>John,
>
>
>> Cygwin uses win32 calls, not crtdll or msvcrt(XX)
>> calls, so the only way you can tell which flags
>> do what is to USE THE SOURCE LUKE ;-)
>> if you have had problems with open, you may
>> be using the wrong headers, DO NOT use vc++
>> or mingw32 headers when building cygwin apps.
>
>The headers are OK, I've checked them: #include <fcntl.h>,
>and this points to the Cygwin fcntl.h.
>
>But:
>
>We are linking Harbour with the MOLDNAME library, could
>this be the problem ?
>
>Victor Szel
>
>
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* BUG: open() O_ flags one bit too high
1999-09-04 18:07 Victor Szel
1999-09-04 23:08 ` Chris Faylor
@ 1999-09-30 23:42 ` Victor Szel
1 sibling, 0 replies; 20+ messages in thread
From: Victor Szel @ 1999-09-30 23:42 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]
Sorry if this is an FRB (Frequently Reported Bug).
It seems that some O_ flags are defined one bit too high in
Cygwin B20 (I've attached cygcheck.out)
Here's the code snippet which deals with that bug in
the source code of the Harbour Project:
#ifdef __CYGWIN__
/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
static inline int FixCygwinIOflags( int flags )
{
/* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
}
#endif
Regards,
Victor Szel
[-- Attachment #2: cygcheck.out --]
[-- Type: text/x-Algol68, Size: 7269 bytes --]
Cygnus Win95/NT Configuration Diagnostics
Current System Time: Sun Sep 05 02:58:53 1999
WinNT Ver 5.0 build 2072
Path: /Program Files/Far
/WINNT/system32
/WINNT
//c/util
//c/util/crack
//c/util/packers
//c/devl/clip52/bin
//c/devl/clipper/bin
//c/work/vtools/util
//C/devl/BC45/BIN
/cygnus/cygwin-b20/H-i586-cygwin32/bin/
SysDir: D:\WINNT\System32
WinDir: D:\WINNT
!C: = `C:\TEMP'
!D: = `D:\_CVS-\harbour\source\rtl'
ALLUSERSPROFILE = `D:\WINNT\Profiles\All Users'
APPDATA = `D:\WINNT\Profiles\Administrator\Application Data'
COMMONPROGRAMFILES = `D:\Program Files\Common Files'
COMPUTERNAME = `VECWS1'
COMSPEC = `D:\WINNT\system32\cmd.exe'
DJGPP = `D:\DEVL\DJGPP\djgpp.env'
HOMEDRIVE = `D:'
HOMEPATH = `\'
INCLUDE = `c:\devl\clip52\include;c:\work\vtools;c:\devl\msc\include;c:\devl\clipper\include'
LIB = `c:\devl\clip52\lib;c:\work\vtools;c:\devl\clipper\lib'
LOGONSERVER = `\\VECWS1'
NUMBER_OF_PROCESSORS = `1'
OBJ = `c:\devl\clip52\obj;c:\work\vtools;c:\devl\clipper\obj'
OS = `Windows_NT'
OS2LIBPATH = `D:\WINNT\system32\os2\dll;'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WS;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 6 Stepping 0, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0600'
PROGRAMFILES = `D:\Program Files'
PROMPT = `$P$G'
SYSTEMDRIVE = `D:'
SYSTEMROOT = `D:\WINNT'
TEMP = `D:\WINNT\Profiles\ADMINI~1\LOCALS~1\Temp'
TMP = `D:\WINNT\Profiles\ADMINI~1\LOCALS~1\Temp'
USERDOMAIN = `VECWS1'
USERNAME = `Administrator'
USERPROFILE = `D:\WINNT\Profiles\Administrator'
WINDIR = `D:\WINNT'
XPPRESOURCE = `d:\program files\ALASKA\XPPW32\RESOURCE'
TERM = `cygwin'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
(default) = `D:'
unix = `/'
fbinary = 0x00000000
fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Microsoft\RAS Autodial\Addresses\sourceware.cygnus.com
(default) = 0x00000002
LastModified = 0x37b9c947
Network = `NETWORK0'
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\Programs\Cygnus Solutions
(default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20\B20.1
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32\i586-cygwin32
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32\i586-cygwin32\cygwin-B20.1
(default) = `d:\cygnus\cygwin-b20'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Management\ARPCache\Cygnus Cygwin B20
(default) = (unsupported type)
Changed = 0x00000000
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Cygnus Cygwin B20
(default) = `D:\WINNT\IsUninst.exe -fd:\cygnus\cygwin-b20\Uninst.isu'
DisplayName = `Cygwin B20'
a:\ fd FAT 1Mb 18% CP UN
c:\ hd FAT 2039Mb 90% CP UN
d:\ hd NTFS 2070Mb 90% CP CS UN PA FC
e:\ cd CDFS 0Mb -2147483548% CS Audio CD
D: / native text!=binary
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\bash.exe
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\cat.exe
Not Found: cpp (good!)
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\find.exe
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\gcc.exe
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\gdb.exe
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\ld.exe
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\ls.exe
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\make.exe
Found: D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\sh.exe
371k 1998/12/01 D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
"cygtcl80.dll" v0.0 ts=1998/12/1 9:25
5k 1998/12/01 D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
10k 1998/12/01 D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
"cygtclreg80.dll" v0.0 ts=1998/12/1 9:25
600k 1998/12/01 D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
"cygtk80.dll" v0.0 ts=1998/12/1 9:28
446k 1998/12/03 D:\cygnus\cygwin-b20\H-i586-cygwin32\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=1998/12/4 5:39
Use -h to see help about each section
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 1:23 ` Victor Szel
1999-09-05 10:04 ` Chris Faylor
@ 1999-09-30 23:42 ` Victor Szel
1 sibling, 0 replies; 20+ messages in thread
From: Victor Szel @ 1999-09-30 23:42 UTC (permalink / raw)
To: cygwin
Chris,
> >#ifdef __CYGWIN__
> >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
> >static inline int FixCygwinIOflags( int flags )
> >{
> > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
> > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
> >}
> >#endif
>
> System O_CREAT (octal) O_CREAT (hex)
> ----------------------------------------------------
> Cygwin 01000 0x200
> Digital UNIX 01000 0x200
> FreeBSD 01000 0x200
> Irix 00400 0x100
> Linux 00100 0x040
> SCO UNIX 3.2 00400 0x100
> Solaris 00400 0x100
> Ultrix 01000 0x200
>
> What was the bug again?
It could be that it's some sort of feature/bug in WinNT and not in Cygwin then,
since the O_CREAT flag passed to open() was 0x200, but open always
returned -1 in this case. WinNT 4.0 SP5 and Win2000 Build 2072 is the
same in this respect. If this is the case, a workaround in Cygwin could be
worth considering.
Victor Szel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 18:38 ` Victor Szel
1999-09-05 19:25 ` Chris Faylor
@ 1999-09-30 23:42 ` Victor Szel
1 sibling, 0 replies; 20+ messages in thread
From: Victor Szel @ 1999-09-30 23:42 UTC (permalink / raw)
To: cygwin
Chris,
> On Sun, Sep 05, 1999 at 10:23:29AM +0200, Victor Szel wrote:
> >> >#ifdef __CYGWIN__
> >> >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
> >> >static inline int FixCygwinIOflags( int flags )
> >> >{
> >> > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
> >> > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
> >> >}
> >> >#endif
> >>
> >> System O_CREAT (octal) O_CREAT (hex)
> >> ----------------------------------------------------
> >> Cygwin 01000 0x200
> >> Digital UNIX 01000 0x200
> >> FreeBSD 01000 0x200
> >> Irix 00400 0x100
> >> Linux 00100 0x040
> >> SCO UNIX 3.2 00400 0x100
> >> Solaris 00400 0x100
> >> Ultrix 01000 0x200
> >>
> >> What was the bug again?
>
> If you are using the open in cygwin then it open() will correctly use
> O_CREAT. It would be inconceivable that this could be wrong. If it
> was, then hundreds of applications would not work.
>
> If you're using cygwin headers in a non-cygwin (aka mingw) application,
> then, um, that's wrong. You should be using another set of headers.
> I'm sure that someone will coment on this and let you know which they
> should be.
Yeah really strange.
One more idea: we are linking MOLDNAME lib, couldn't that be a problem.
BTW we are including <mingw32/share.h> and <fcntl.h>, so the flags should
be OK, but it seems that the open() function is executed from the MFC DLL
which uses different flag values.
Victor Szel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-04 23:08 ` Chris Faylor
1999-09-05 1:23 ` Victor Szel
@ 1999-09-30 23:42 ` Chris Faylor
1 sibling, 0 replies; 20+ messages in thread
From: Chris Faylor @ 1999-09-30 23:42 UTC (permalink / raw)
To: Victor Szel; +Cc: cygwin
On Sun, Sep 05, 1999 at 03:07:49AM +0200, Victor Szel wrote:
>Sorry if this is an FRB (Frequently Reported Bug).
>
>It seems that some O_ flags are defined one bit too high in
>Cygwin B20 (I've attached cygcheck.out)
>
>Here's the code snippet which deals with that bug in
>the source code of the Harbour Project:
>
>#ifdef __CYGWIN__
>/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
>static inline int FixCygwinIOflags( int flags )
>{
> /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
> return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
>}
>#endif
System O_CREAT (octal) O_CREAT (hex)
----------------------------------------------------
Cygwin 01000 0x200
Digital UNIX 01000 0x200
FreeBSD 01000 0x200
Irix 00400 0x100
Linux 00100 0x040
SCO UNIX 3.2 00400 0x100
Solaris 00400 0x100
Ultrix 01000 0x200
What was the bug again?
-Chris Faylor
-Win32 Manager
-Cygnus Solutions
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-06 5:25 Earnie Boyd
@ 1999-09-30 23:42 ` Earnie Boyd
0 siblings, 0 replies; 20+ messages in thread
From: Earnie Boyd @ 1999-09-30 23:42 UTC (permalink / raw)
To: Victor Szel, cygwin
--- Victor Szel <info@szelvesz.hu> wrote:
-8<-
> Yeah really strange.
>
> One more idea: we are linking MOLDNAME lib, couldn't that be a problem.
> BTW we are including <mingw32/share.h> and <fcntl.h>, so the flags should
> be OK, but it seems that the open() function is executed from the MFC DLL
> which uses different flag values.
-8<-
Victor, I'm confused with this thread and if I'm confused I'm sure others are
too. What exactly, are you trying to do? Are you using cygwin to create a
non-cygwin program? What's being linked with what, give an example of your
build? Are you mixing and matching package headers, (you're in trouble if that
is the case)? Provide the output of `cygcheck -s -v -r' either pasted or
attached in plain text format. If you attach it has to be plain text for me to
read it.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 10:04 ` Chris Faylor
1999-09-05 18:38 ` Victor Szel
@ 1999-09-30 23:42 ` Chris Faylor
1 sibling, 0 replies; 20+ messages in thread
From: Chris Faylor @ 1999-09-30 23:42 UTC (permalink / raw)
To: Victor Szel; +Cc: cygwin
On Sun, Sep 05, 1999 at 10:23:29AM +0200, Victor Szel wrote:
>> >#ifdef __CYGWIN__
>> >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
>> >static inline int FixCygwinIOflags( int flags )
>> >{
>> > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
>> > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
>> >}
>> >#endif
>>
>> System O_CREAT (octal) O_CREAT (hex)
>> ----------------------------------------------------
>> Cygwin 01000 0x200
>> Digital UNIX 01000 0x200
>> FreeBSD 01000 0x200
>> Irix 00400 0x100
>> Linux 00100 0x040
>> SCO UNIX 3.2 00400 0x100
>> Solaris 00400 0x100
>> Ultrix 01000 0x200
>>
>> What was the bug again?
>
>It could be that it's some sort of feature/bug in WinNT and not in Cygwin then,
>since the O_CREAT flag passed to open() was 0x200, but open always
>returned -1 in this case. WinNT 4.0 SP5 and Win2000 Build 2072 is the
>same in this respect. If this is the case, a workaround in Cygwin could be
>worth considering.
If you are using the open in cygwin then it open() will correctly use
O_CREAT. It would be inconceivable that this could be wrong. If it
was, then hundreds of applications would not work.
If you're using cygwin headers in a non-cygwin (aka mingw) application,
then, um, that's wrong. You should be using another set of headers.
I'm sure that someone will coment on this and let you know which they
should be.
-chris
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 19:25 ` Chris Faylor
@ 1999-09-30 23:42 ` Chris Faylor
0 siblings, 0 replies; 20+ messages in thread
From: Chris Faylor @ 1999-09-30 23:42 UTC (permalink / raw)
To: Victor Szel; +Cc: cygwin
On Mon, Sep 06, 1999 at 03:38:07AM +0200, Victor Szel wrote:
>> If you're using cygwin headers in a non-cygwin (aka mingw) application,
>> then, um, that's wrong. You should be using another set of headers.
>> I'm sure that someone will coment on this and let you know which they
>> should be.
>
>Yeah really strange.
>
>One more idea: we are linking MOLDNAME lib, couldn't that be a problem.
>BTW we are including <mingw32/share.h> and <fcntl.h>, so the flags should
>be OK, but it seems that the open() function is executed from the MFC DLL
>which uses different flag values.
As far as I can see, the mingw headers match the VC++ headers. Both define
O_CREAT as 0x100.
It sure sounds like you are not using the mingw headers.
-chris
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
@ 1999-09-06 5:25 Earnie Boyd
1999-09-30 23:42 ` Earnie Boyd
0 siblings, 1 reply; 20+ messages in thread
From: Earnie Boyd @ 1999-09-06 5:25 UTC (permalink / raw)
To: Victor Szel, cygwin
--- Victor Szel <info@szelvesz.hu> wrote:
-8<-
> Yeah really strange.
>
> One more idea: we are linking MOLDNAME lib, couldn't that be a problem.
> BTW we are including <mingw32/share.h> and <fcntl.h>, so the flags should
> be OK, but it seems that the open() function is executed from the MFC DLL
> which uses different flag values.
-8<-
Victor, I'm confused with this thread and if I'm confused I'm sure others are
too. What exactly, are you trying to do? Are you using cygwin to create a
non-cygwin program? What's being linked with what, give an example of your
build? Are you mixing and matching package headers, (you're in trouble if that
is the case)? Provide the output of `cygcheck -s -v -r' either pasted or
attached in plain text format. If you attach it has to be plain text for me to
read it.
===
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 18:38 ` Victor Szel
@ 1999-09-05 19:25 ` Chris Faylor
1999-09-30 23:42 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
1 sibling, 1 reply; 20+ messages in thread
From: Chris Faylor @ 1999-09-05 19:25 UTC (permalink / raw)
To: Victor Szel; +Cc: cygwin
On Mon, Sep 06, 1999 at 03:38:07AM +0200, Victor Szel wrote:
>> If you're using cygwin headers in a non-cygwin (aka mingw) application,
>> then, um, that's wrong. You should be using another set of headers.
>> I'm sure that someone will coment on this and let you know which they
>> should be.
>
>Yeah really strange.
>
>One more idea: we are linking MOLDNAME lib, couldn't that be a problem.
>BTW we are including <mingw32/share.h> and <fcntl.h>, so the flags should
>be OK, but it seems that the open() function is executed from the MFC DLL
>which uses different flag values.
As far as I can see, the mingw headers match the VC++ headers. Both define
O_CREAT as 0x100.
It sure sounds like you are not using the mingw headers.
-chris
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 10:04 ` Chris Faylor
@ 1999-09-05 18:38 ` Victor Szel
1999-09-05 19:25 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
1999-09-30 23:42 ` Chris Faylor
1 sibling, 2 replies; 20+ messages in thread
From: Victor Szel @ 1999-09-05 18:38 UTC (permalink / raw)
To: cygwin
Chris,
> On Sun, Sep 05, 1999 at 10:23:29AM +0200, Victor Szel wrote:
> >> >#ifdef __CYGWIN__
> >> >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
> >> >static inline int FixCygwinIOflags( int flags )
> >> >{
> >> > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
> >> > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
> >> >}
> >> >#endif
> >>
> >> System O_CREAT (octal) O_CREAT (hex)
> >> ----------------------------------------------------
> >> Cygwin 01000 0x200
> >> Digital UNIX 01000 0x200
> >> FreeBSD 01000 0x200
> >> Irix 00400 0x100
> >> Linux 00100 0x040
> >> SCO UNIX 3.2 00400 0x100
> >> Solaris 00400 0x100
> >> Ultrix 01000 0x200
> >>
> >> What was the bug again?
>
> If you are using the open in cygwin then it open() will correctly use
> O_CREAT. It would be inconceivable that this could be wrong. If it
> was, then hundreds of applications would not work.
>
> If you're using cygwin headers in a non-cygwin (aka mingw) application,
> then, um, that's wrong. You should be using another set of headers.
> I'm sure that someone will coment on this and let you know which they
> should be.
Yeah really strange.
One more idea: we are linking MOLDNAME lib, couldn't that be a problem.
BTW we are including <mingw32/share.h> and <fcntl.h>, so the flags should
be OK, but it seems that the open() function is executed from the MFC DLL
which uses different flag values.
Victor Szel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-05 1:23 ` Victor Szel
@ 1999-09-05 10:04 ` Chris Faylor
1999-09-05 18:38 ` Victor Szel
1999-09-30 23:42 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
1 sibling, 2 replies; 20+ messages in thread
From: Chris Faylor @ 1999-09-05 10:04 UTC (permalink / raw)
To: Victor Szel; +Cc: cygwin
On Sun, Sep 05, 1999 at 10:23:29AM +0200, Victor Szel wrote:
>> >#ifdef __CYGWIN__
>> >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
>> >static inline int FixCygwinIOflags( int flags )
>> >{
>> > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
>> > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
>> >}
>> >#endif
>>
>> System O_CREAT (octal) O_CREAT (hex)
>> ----------------------------------------------------
>> Cygwin 01000 0x200
>> Digital UNIX 01000 0x200
>> FreeBSD 01000 0x200
>> Irix 00400 0x100
>> Linux 00100 0x040
>> SCO UNIX 3.2 00400 0x100
>> Solaris 00400 0x100
>> Ultrix 01000 0x200
>>
>> What was the bug again?
>
>It could be that it's some sort of feature/bug in WinNT and not in Cygwin then,
>since the O_CREAT flag passed to open() was 0x200, but open always
>returned -1 in this case. WinNT 4.0 SP5 and Win2000 Build 2072 is the
>same in this respect. If this is the case, a workaround in Cygwin could be
>worth considering.
If you are using the open in cygwin then it open() will correctly use
O_CREAT. It would be inconceivable that this could be wrong. If it
was, then hundreds of applications would not work.
If you're using cygwin headers in a non-cygwin (aka mingw) application,
then, um, that's wrong. You should be using another set of headers.
I'm sure that someone will coment on this and let you know which they
should be.
-chris
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-04 23:08 ` Chris Faylor
@ 1999-09-05 1:23 ` Victor Szel
1999-09-05 10:04 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
1999-09-30 23:42 ` Chris Faylor
1 sibling, 2 replies; 20+ messages in thread
From: Victor Szel @ 1999-09-05 1:23 UTC (permalink / raw)
To: cygwin
Chris,
> >#ifdef __CYGWIN__
> >/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
> >static inline int FixCygwinIOflags( int flags )
> >{
> > /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
> > return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
> >}
> >#endif
>
> System O_CREAT (octal) O_CREAT (hex)
> ----------------------------------------------------
> Cygwin 01000 0x200
> Digital UNIX 01000 0x200
> FreeBSD 01000 0x200
> Irix 00400 0x100
> Linux 00100 0x040
> SCO UNIX 3.2 00400 0x100
> Solaris 00400 0x100
> Ultrix 01000 0x200
>
> What was the bug again?
It could be that it's some sort of feature/bug in WinNT and not in Cygwin then,
since the O_CREAT flag passed to open() was 0x200, but open always
returned -1 in this case. WinNT 4.0 SP5 and Win2000 Build 2072 is the
same in this respect. If this is the case, a workaround in Cygwin could be
worth considering.
Victor Szel
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: BUG: open() O_ flags one bit too high
1999-09-04 18:07 Victor Szel
@ 1999-09-04 23:08 ` Chris Faylor
1999-09-05 1:23 ` Victor Szel
1999-09-30 23:42 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
1 sibling, 2 replies; 20+ messages in thread
From: Chris Faylor @ 1999-09-04 23:08 UTC (permalink / raw)
To: Victor Szel; +Cc: cygwin
On Sun, Sep 05, 1999 at 03:07:49AM +0200, Victor Szel wrote:
>Sorry if this is an FRB (Frequently Reported Bug).
>
>It seems that some O_ flags are defined one bit too high in
>Cygwin B20 (I've attached cygcheck.out)
>
>Here's the code snippet which deals with that bug in
>the source code of the Harbour Project:
>
>#ifdef __CYGWIN__
>/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
>static inline int FixCygwinIOflags( int flags )
>{
> /* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
> return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
>}
>#endif
System O_CREAT (octal) O_CREAT (hex)
----------------------------------------------------
Cygwin 01000 0x200
Digital UNIX 01000 0x200
FreeBSD 01000 0x200
Irix 00400 0x100
Linux 00100 0x040
SCO UNIX 3.2 00400 0x100
Solaris 00400 0x100
Ultrix 01000 0x200
What was the bug again?
-Chris Faylor
-Win32 Manager
-Cygnus Solutions
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* BUG: open() O_ flags one bit too high
@ 1999-09-04 18:07 Victor Szel
1999-09-04 23:08 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
0 siblings, 2 replies; 20+ messages in thread
From: Victor Szel @ 1999-09-04 18:07 UTC (permalink / raw)
To: cygwin
Sorry if this is an FRB (Frequently Reported Bug).
It seems that some O_ flags are defined one bit too high in
Cygwin B20 (I've attached cygcheck.out)
Here's the code snippet which deals with that bug in
the source code of the Harbour Project:
#ifdef __CYGWIN__
/* TODO: Get Cygwin fixed so that this bug fix won't be needed */
static inline int FixCygwinIOflags( int flags )
{
/* Starting with O_CREAT, the Cygwin I/O flags are 1 bit too high */
return ( ( flags & 0x1FF00 ) >> 1 ) | ( flags & 0xFF );
}
#endif
Regards,
Victor Szel
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~1999-09-30 23:42 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-05 3:00 BUG: open() O_ flags one bit too high Victor Szel
1999-09-05 3:33 ` John R Hanson
[not found] ` <013701bef7a0$92bd7370$0a0ac8c8@VECWS1>
1999-09-05 22:46 ` John R Hanson
1999-09-30 23:42 ` John R Hanson
1999-09-30 23:42 ` John R Hanson
1999-09-30 23:42 ` Victor Szel
-- strict thread matches above, loose matches on Subject: below --
1999-09-06 5:25 Earnie Boyd
1999-09-30 23:42 ` Earnie Boyd
1999-09-04 18:07 Victor Szel
1999-09-04 23:08 ` Chris Faylor
1999-09-05 1:23 ` Victor Szel
1999-09-05 10:04 ` Chris Faylor
1999-09-05 18:38 ` Victor Szel
1999-09-05 19:25 ` Chris Faylor
1999-09-30 23:42 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
1999-09-30 23:42 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
1999-09-30 23:42 ` Chris Faylor
1999-09-30 23:42 ` Victor Szel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).