[PATCH] open O_TEXT and O_BINARY for cygwin/windows

Max Bowsher maxb at ukf.net
Sun Jan 26 20:55:00 EST 2003


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 normal
usage.

Max.




> 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
> that has a Windows filesystem mounted.
>
> - Dave
>
> On Sun, Jan 26, 2003 at 12:07:07PM -0800, Wayne Davison wrote:
>> 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 both Mac and PC line endings, so I removed
>> the O_TEXT bit from these.
>>
>>> clientserver.c:         FILE *f = fopen(motd,"r" O_TEXT_STR);
>>> simply passes contents of motd file unchanged to client
>>> does it matter if there are \r chars in the file?
>>
>> I'm trying to imagine what will happen for Mac systems as well.
>> Since the default for files is to open them in text mode on a Mac
>> (and they don't have the Cygwin weirdness of trying to override a
>> binary-mode mount, right?), then I think you're right here -- the
>> extra \r that might come from a PC system should hopefully cause no
>> problems (but we should test this).  In the meantime, I think it
>> would be safe to revert this change.
>>
>>> exclude.c:              f = fopen(fname,"r" O_TEXT_STR);
>>> exclude.c:              f = fdopen(0, "r" O_TEXT_STR);
>>> the file is processed with
>>> while (fgets(line,MAXPATHLEN,f)) {
>>> int l = strlen(line);
>>> if (l && line[l-1] == '\n') l--;
>>> line[l] = 0;
>>> if we add
>>> if (l && line[l-1] == '\r') l--;
>>> after the \n processing that will handle the \r\n case
>>> or we can replace the \n line with
>>> while (l && (line[l-1] == '\n'|| line[l-1] == '\r')) l--;
>>> and this function will be covered.
>>
>> As long as Mac systems are reading the file in text mode without the
>> O_TEXT_STR, we should be fine (and I believe that to be the case).
>>
>>> params.c:  OpenedFile = fopen( FileName, "r" O_TEXT_STR );
>>> since \r is a whitespace character it should be
>>> ignored.
>>
>> Sounds right (though I haven't verified your analysis).
>>
>> Since it sounds like the "t" has a potential for problems, I'm taking
>> these recent changes out and will just put in the one suggested
>> change to ignore a '\r' at the end of the line.  This should be
>> safer for the current release.
>>
>> ...wayne..




More information about the rsync mailing list