Dave Dykstra wrote:
I suspect it's also the
reason why the build.samba.org cygwin machine hasn't reported a result
in the last 9 hours.
Nope.. problems with the CPU fan-cooler =(
I'm taking it back out and washing my hands of the cygwin rsync port, I'm fed up.
I'll catch up with Max doscove
On Tue, Jan 28, 2003 at 01:26:32PM -, Max Bowsher wrote:
> Dave Dykstra wrote:
> > I give up. The msleep(100) consistently causes hangs of the
> > unsafe-links test on my friend's cygwin Windows 2000 machine. I
> > suspect it's also the reason why the build.samba.org cygwin machine
> > hasn't
Dave Dykstra wrote:
> I give up. The msleep(100) consistently causes hangs of the
> unsafe-links test on my friend's cygwin Windows 2000 machine. I
> suspect it's also the reason why the build.samba.org cygwin machine
> hasn't reported a result in the last 9 hours. I'm taking it back out
> and w
On Mon, Jan 27, 2003 at 04:01:46PM -0600, Dave Dykstra wrote:
> On Mon, Jan 27, 2003 at 04:45:25PM -, Max Bowsher wrote:
...
> > Cygwin has gone through many minor versions since then. I suggest releasing
> > an rsync without the hack, but with a command line option to turn it on.
> > That way,
On Mon, Jan 27, 2003 at 04:45:25PM -, Max Bowsher wrote:
> Dave Dykstra wrote:
> > On Mon, Jan 27, 2003 at 10:46:16AM +0100, Lapo Luchini wrote:
> >> I can test that before releasing cygwin's 2.5.6-1 package,
> >> unfortunately I have almost *no* free time until after friday
> >> (university te
Dave Dykstra wrote:
> On Mon, Jan 27, 2003 at 10:46:16AM +0100, Lapo Luchini wrote:
>> I can test that before releasing cygwin's 2.5.6-1 package,
>> unfortunately I have almost *no* free time until after friday
>> (university test on thursday ^_^)
>> Anyway Max is also right, local issues can be re
On Mon, Jan 27, 2003 at 10:46:16AM +0100, Lapo Luchini wrote:
> Dave Dykstra wrote:
>
> >>What, in particular? I'm not a very good testcase, because I use binary
> >>mounts and unix line endings everywhere.
> >>
> >>It compiles and does syncs with remote rsync daemons, which is my normal
> >>usage
Dave Dykstra wrote:
What, in particular? I'm not a very good testcase, because I use binary
mounts and unix line endings everywhere.
It compiles and does syncs with remote rsync daemons, which is my normal
usage.
Max.
See if exclude files with DOS line endings work ok for you, and also the
Dave Dykstra wrote:
> On Sun, Jan 26, 2003 at 08:54:19PM -, Max Bowsher wrote:
>> Dave Dykstra wrote:
>>> Alright. Max, could you quickly verify if the latest CVS version
>>> works OK for you on Cygwin?
>>
>> What, in particular? I'm not a very good testcase, because I use
>> binary mounts and
On Sun, Jan 26, 2003 at 08:54:19PM -, Max Bowsher wrote:
> Dave Dykstra wrote:
> > Alright. Max, could you quickly verify if the latest CVS version
> > works OK for you on Cygwin?
>
> What, in particular? I'm not a very good testcase, because I use binary
> mounts and unix line endings everyw
Dave Dykstra wrote:
> Alright. Max, could you quickly verify if the latest CVS version
> works OK for you on Cygwin?
What, in particular? I'm not a very good testcase, because I use binary
mounts and unix line endings everywhere.
It compiles and does syncs with remote rsync daemons, which is my
Alright. Max, could you quickly verify if the latest CVS version works
OK for you on Cygwin?
It's better to always handle all three styles of line terminations anyway,
because there are other situations than systems that have O_TEXT defined
where it might be wanted, for example a Linux system tha
On Sun, Jan 26, 2003 at 08:16:50AM -0800, jw schultz wrote:
> authenticate.c: fd = open(fname,O_RDONLY | O_TEXT);
> get_secret() already discards \r
>
> authenticate.c: if ( (fd=open(filename,O_RDONLY | O_TEXT)) == -1) {
> getpassf() treats \r the same as \n
Yeah, these already handle
On Sun, Jan 26, 2003 at 09:43:06AM -0500, Green, Paul wrote:
> Ville Herva [mailto:[EMAIL PROTECTED]] wrote:
> > Of course, whether O_TEXT is defined or not does not
> > necessarily imply the availability of "t", but I
> > can't think of better alternative.
>
> Stratus VOS implements O_TEXT and O
Ville Herva [mailto:[EMAIL PROTECTED]] wrote:
> Of course, whether O_TEXT is defined or not does not
> necessarily imply the availability of "t", but I
> can't think of better alternative.
Stratus VOS implements O_TEXT and O_BINARY but does not recognize "t". We
have the options defined in ANS C
On Sat, Jan 25, 2003 at 01:43:39AM -0800, you [jw schultz] wrote:
> On Sat, Jan 25, 2003 at 10:56:37AM +0200, Ville Herva wrote:
> > On Fri, Jan 24, 2003 at 05:09:43PM -0600, you [Dave Dykstra] wrote:
> > >
> > > I think I'll go ahead and put in your patch with the modification of
> > > using O_TEX
On Sat, Jan 25, 2003 at 10:56:37AM +0200, Ville Herva wrote:
> On Fri, Jan 24, 2003 at 05:09:43PM -0600, you [Dave Dykstra] wrote:
> >
> > I think I'll go ahead and put in your patch with the modification of using
> > O_TEXT_STR as you suggest.
>
> Thanks.
>
> > I think the risk is low.
>
>
On Fri, Jan 24, 2003 at 05:09:43PM -0600, you [Dave Dykstra] wrote:
>
> I think I'll go ahead and put in your patch with the modification of using
> O_TEXT_STR as you suggest.
Thanks.
> I think the risk is low.
I think so, too.
> I had been concerned that perhaps older CPPs might not be abl
On Fri, Jan 24, 2003 at 08:57:02AM +0200, Ville Herva wrote:
> On Thu, Jan 23, 2003 at 01:55:40PM -0600, you [Dave Dykstra] wrote:
> > Why did you skip the fopen in log.c, which appends to the log file?
>
> I thought about that for a while. My reasoning was that the log file is
> probably read wit
Ville Herva wrote:
> On Thu, Jan 23, 2003 at 01:55:40PM -0600, you [Dave Dykstra] wrote:
>> Why did you skip the fopen in log.c, which appends to the log file?
>
> I thought about that for a while. My reasoning was that the log file
> is probably read with unix/cygwin tools anyway - if not, the
> a
On Thu, Jan 23, 2003 at 01:55:40PM -0600, you [Dave Dykstra] wrote:
> Why did you skip the fopen in log.c, which appends to the log file?
I thought about that for a while. My reasoning was that the log file is
probably read with unix/cygwin tools anyway - if not, the administrator is
free to mount
Why did you skip the fopen in log.c, which appends to the log file?
Because of the question about whether or not the "t" is ignored on all
platforms, I'm a little nervous about putting this into 2.5.6. I don't
have any problem with it for 2.6.0. Maybe it should be just in the
'patches' directory
> > perhaps you would want to consider the "force binary open for data files
> > on CYGWIN" -patch I sent ages ago? I feel it's quite important, and to
> > me it never makes sense to open data files in ascii (CR/LF translation
> > mode) nor config files in BINARY mode (opening them in ascii makes i
23 matches
Mail list logo
