HP-UX 11i and largefiles on rsync 2.6.2

[Steve Bonds]

On Thu, 29 Jul 2004, Chris Shoemaker c.shoemaker-at-cox.net |Rsync List| wrote:

> On Wed, Jul 28, 2004 at 10:57:58AM -0700, Steve Bonds wrote:

> > The mkstemp man page suggests using tmpfile() instead, which
> > generally means that HP won't fix any problems.
> >
> > ----- mktemp(3C)
> >     Remarks:
> >       These functions are provided solely for backward compatibility and
> >       importability of applications, and are not recommended for new
> >       applications where portability is important.  For portable
> >       applications, use tmpfile() instead (see tmpfile(3S)).
> > -----
>
> Maybe we should follow this advice.

This is actually terrible advice because of the race condition mentioned
below.  For example, from the Linux man page for tmpnam(3):

-----
BUGS
Never use this function. Use mkstemp(3) instead.
-----

I tend to agree with that sentiment.  ;-)

> > The tempnam()/tmpfile() combination seems particularly difficult to use
> > compared with mkstemp().  I especially liked this warning:
> >
> > ----- tmpnam(3S)
> > WARNINGS
> >    Between the time a file name is created and the file is opened, it is
> >    possible for some other process to create a file with the same name.
> >    This can never happen if that other process is using these functions
> >    or mktemp, and the file names are chosen such that duplication by
> >    other means is unlikely.
> > -----
>
> Can we use tmpfile without tmpname?

No, since rsync should create the temp file in the same directory as the
final destination file.  There is no way to feed a "template" to tmpfile
to tell it where to create the file, so they all generally end up in /tmp
unless the system defines a really odd default location.

If rsync didn't create the file in the same directory I can see two
issues:
  1) Filling up /tmp on large file transfers
  2) Instead of a fast rename in the same filesystem, the whole
     contents of the file would need to be copied out of /tmp to
     the final location, slowing things down significantly

  -- Steve