Codereview needed for #6929479

[Martin Buchholz]

I think some documentation of the problem,
and a practical description of how users can
deal with it, is the most important thing.
Old unix-isms, like

cp test/foo.jar production/foo.jar
jar cf production/foo.jar ...
some...unix..command > production/foo.jar
rsync -a test/ production/

need to be exposed as avoidable (!) sources of SIGBUS.

I only recently learned about the following option
to rsync, which I have started using religiously
to try to reduce SIGBUS for my own customers:

       --delay-updates
              This option puts the temporary file from each updated file  into
              a holding directory until the end of the transfer, at which time
              all the files are renamed into place in rapid succession.   This
              attempts to make the updating of the files a little more atomic.
              By default the files are placed into a directory named "~tmp~"
              in  each file's destination directory, but if you've specified
              the --partial-dir option, that directory will be  used  instead.
              See  the  comments in the --partial-dir section for a discussion
              of how this ".~tmp~" dir will be excluded from the transfer, and
              what  you  can do if you want rsync to cleanup old "~tmp~" dirs
              that might  be  lying  around.   Conflicts  with  --inplace  and
              --append.

Feel free to turn this email into educational material that
might reduce the SIGBUSes real users will encounter.

Martin

On Thu, Feb 25, 2010 at 11:09, Xueming Shen <Xueming.Shen at sun.com> wrote:
>
> http://cr.openjdk.java.net/~sherman/6929479/webrev/
>
> This is a rfe to add a system property sun.zip.disableMmap to enable the end
> user to disable the mmap usage in
> Sun's java.util.zip.ZipFile implementaiton (for Solaris and Linux
> platforms).
>
> Application uses java.util.zip.ZipFile might experience SIGBUS vm crash if
> the application mistakely over-writes
> zip/jar files that are still being used, for example the application server
> repeatedly deploy the same jar file into the
> same location again and again while there is still code (running in the same
> vm)  still accessing this particular zip/
> jar file (access the memory that mmapped the central directory of the zip
> file). While this is indeed an programming
> error in the offending application, there is situation that the end user
> really does not have the control of those
> applications and look for a workaround for the crash. With this property set
> to true (-Dsun.zip.disableMmap=true)
> the sun zipfile implementation reads in the central directory into the
> memory instead of using mmap.
>
> Thanks,
> Sherman
>