rsync - Jan 2003 - [PATCH] open O_TEXT and O_BINARY for cygwin/windows

Ville Herva [mailto:vherva@niksula.hut.fi] 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 and in POSIX. I'm at home and don't
have
my reference materials handy, but I think this is going to be a problem for
us. I can see looking at the code that we will reject the open if we see
unknown letters.

Please write a configure test.  Even if we are wrong and we should be
ignoring it, I have hundreds of machines in the field and it will be years
before they are upgraded.

The string concatenation thing is not an issue here.

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Computer, Inc.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.
Speaking from Stratus not for Stratus

On Sun, Jan 26, 2003 at 09:43:06AM -0500, Green, Paul
wrote:
> Ville Herva [mailto:vherva@niksula.hut.fi] 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 and in POSIX. I'm at home and
don't have
> my reference materials handy, but I think this is going to be a problem for
> us. I can see looking at the code that we will reject the open if we see
> unknown letters.
> 
> Please write a configure test.  Even if we are wrong and we should be
> ignoring it, I have hundreds of machines in the field and it will be years
> before they are upgraded.
> 
> The string concatenation thing is not an issue here.
On the systems where O_TEXT and "rt" have meaning are we
looking at anything other than converting "\r\n" to "\n"?
If not i don't think we need the O_TEXT stuff.

I did a quick survey of where you have the O_TEXT and O_TEXT_STR
and of the one other calls to fopen (logfile).

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

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?

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.

	
params.c:  OpenedFile = fopen( FileName, "r" O_TEXT_STR );
	since \r is a whitespace character it should be
	ignored.

Based on this i don't think we need to worry about O_TEXT or
"rt" mode.  The only place i can imagine we might want text
mode is the log file and i imagine that admins can cope with
EOL issues.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt