rsync-2.4.7 NEWS file

[John E. Malmberg]

On Mon, 6 Aug 2001 rsync-request at lists.samba.org wrote:

> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.samba.org/mailman/listinfo/rsync
>
> Today's Topics:
> 
>    1. rsync-2.4.7 NEWS file (Martin Pool)

Martin Pool <mbp at valinux.company> wrote:
> 
> I've gone through the CVS commit log and tried to get every
> user-visible change since 2.4.6, so that we can make a proper
> announcement for 2.4.7.  Please let me know if anything is
> missing/inaccurate.
> 
> At this stage I'm planning to release two 2.4.7pre tarballs, one with
> the "large nohang patch" and one without.  Some people inside VA will
> be stress-testing both, and so we can see which one works out best.
> It seems like most reports on this list like the patch, but I think
> tridge is still conceerned that it will cause too much memory
> allocation.

I look forward to seeing the "pre" tarballs.

I am starting to port RSYNC to OpenVMS, and with 2.4.6 there are a number
of issues that it would help me if they were fixed.

Because of being a bit internet impaired, I can not supply diff files
until tomorrow, and I am going from my memory, and it may be better if
I apply my changes to 2.4.7pre instead.

I currently have the source code (with some patches) compiling cleanly
with the Compaq C compiler in a -WALL mode.

The first issue that comes up is that at this time, I can not support
hardlinks.

Some of the code will not honor the config.h's settings on this, and will
compile in references to other routines that are not compiled as they are
honoring config.h.

This would lead me to beleive it is a bug.

I also do not have the UNIX SYSLOG API.
The SYSLOG checks also continue to expect some of the SYSLOG definitions
to be present even when CONFIG.H says otherwise.

Compaq C will not compile code where a function prototype of a
standard library call is placed in the code that is not type compatable
with the standard headers that were previously #included.

This compiler is common to OpenVMS, Tru-64, and LINUX on Alpha.


The Compaq C compiler on OpenVMS by default has char as a signed type.
The rsync code seems to be generally assuming that char is unsigned.
The compiler will flag a type mismatch when attempting to pass an
(unsigned char) to a (char) procedure parameter or assignment.  On
examining the code where these were flagged, it appears that a number of
char arrays where really being used as unsinged char arrays.

Several of the prototypes of functions with no parameters were missing the
(void) tag.

A few cases, most notably the return from a strlen() call, the code is
testing to see if it is greater than 0.  As the size_t type is unsigned,
it is not possible for this value to be less than 0, so the compiler is
concerned that (unsinged > 0) might fail to detect a routine that returns
a negative value cast to an unsigned value.  A change to (unsigned != 0)
clarifies this.  The compiler generates the same output code in either
case, but the second expression makes it clear that the only real test is
for non-zero.

The Compaq C compiler is also flaging all #if statements that reference an
undefined macro symbol in their line.


There are two OpenVMS issues for compiling.

One is that my build environment is using a search list, to keep my VMS
specific patched files separate from a read only directory tree containing
the UNIX rsync source.

Once consequence of this is that the compiler can not handle include files
of the type "..\foo.h".  I can deal with "foo.h" and tell the compiler
where find the files, or I can use "zlib\foo.h" and tell the compiler
where zlib is.


The other is more tricky, as those of you that have read my posts on the
SAMBA technical list have seen, OpenVMS has a 48 bit inode.  Since at the
time C was introduced to OpenVMS, only 32 bit integers were available,
this inode was represented in the struct stat as unsigned short st_ino[3].

As a result all assignments and comparisons for inodes must be done
through memcpy() and memcmp().  I have worked out macros that should
resolve to memcpy() and memcmp() on OpenVMS, but resolve to normal code on
UNIX platforms.  I do not know of any other platform with an inode type
that can be larger than the largest integer value on the platform.

All of these patches that I have made to 2.4.6 were done from editor
scripts, so I should be able to unpack 2.4.7pre and quickly see how that
build gos.


I still do not have a runable executable, as I have to deal with
converting the forked process to an OpenVMS AST thread, and a few other
issues with file formats.  So this means that for execution purposes,
my patches are untested.


> rsync 2.4.7 (sometime in 2001, maybe :)
> 
>     * Change to using libpopt rather than getopt for processing
>       options.  This makes the code cleaner and the behaviour more
>       consistent across platforms.  popt is included and built if not
>       installed on the platform.

Note, I have a modified gnu getopt() that handles commands in a more
OpenVMS friendly format.  I will have to see if this is a step backwards
for me.

The basic differences are that OpenVMS users are used to using "/" where
the gnu code uses "--", and that "foo=value" can be also specified as
"foo:value".



I also have some Compaq OpenVMS specific issues to resolve:

1. I see references to uid and gid's of -1, and -2.  Are these flags
   the program, or do they map to a specific special UNIX user or group?

2. OpenVMS has a variety of internal file formats.  It can send out the
   formats commonly used for text and binary files in a format that
   UNIX can use them.  When receiving an update to an existing file I
   think I can find a way to make sure that the orignal internal file
   format is used.

   However, this conversion process is lossy.  The format information is
   lost.  Also some of the OpenVMS file types are unsuable if this format
   information is lost.  The types that are unusable would not normally
   be readable on a non-OpenVMS host.

   It is for when two OpenVMS hosts are using RSYNC, I need to be able to
   identify this, so that I can send that information to the receiver.
   This would allow rsync to be fully functional between two OpenVMS
   systems.

   For files that are obviously not text files, and therefore not portable
   between operating systems, I was going to append the file format
   information to the end of the file name, with some character (not yet
   chosen) to indicate a delimiter.  When copied to a non-OpenVMS system,
   they would have a funny name, but if that RSYNC server then served them
   to another OpenVMS machine, it would then be able to correctly open
   the file.

   If someone has suggestions for a character to delimit the file from
   it's OpenVMS attributes, I am interested.  I am leaning toward the
   exclamation mark as it is a comment flag to the OpenVMS shell.

   If there are other suggestions on how a file server can give what
   hints it knows about the use of a file it is serving on a portable
   nature, I am also interested.


   There may be other issues I come up with as well.  The OpenVMS file
   system does the wildcard expansion, not the shell.  This changes
   the efficiencies of some algorthms.


-John
wb8tyw at qsl.network
Personal Opinion Only.