mirror of
https://github.com/RsyncProject/rsync.git
synced 2026-05-30 17:58:10 -04:00
0af88421dc
Fold the standalone rsync-web repo into the rsync source tree as rsync-web/, eliminating the sibling-checkout convention and the drift it causes between the release-time HTML snapshot in ../release/rsync-html and the source of truth in ../rsync-web. Flat-copy import (no git history merge). The standalone repo at github.com/RsyncProject/rsync-web is retained for historical reference and will be archived once the in-tree copy proves itself. Add /rsync-web/ to .gitattributes with export-ignore so the website content does not bloat the release source tarball produced by 'git archive' in packaging/release.py step_7_tarball. A follow-up commit repoints HTML_SRC in packaging/release.py at the new in-tree location.
25 lines
884 B
HTML
25 lines
884 B
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>rsync y2k issues</TITLE>
|
|
</HEAD>
|
|
<!--#include virtual="header.html" -->
|
|
|
|
<H2 align="center">Year 2000 Issues</H2>
|
|
|
|
We are starting to get a lot of Y2K compliance questions. The answer
|
|
is that rsync has no Y2K problems. rsync uses 32 bit "seconds since
|
|
1970" date formats and thus has no problems with the turn of the
|
|
century.<p>
|
|
|
|
You must remember though that rsync is part of a larger system. It
|
|
relies on a transport mechanism (rsh, ssh etc) and many operating
|
|
systems services (such as inetd, syslog etc). If any of these other
|
|
parts fail then rsync will of course be affected.<p>
|
|
|
|
Also remember that rsync comes with absolutely no warranty. It is up
|
|
to you to test whether rsync is suitable in your computing environment,
|
|
both before and after the turn of the century.
|
|
|
|
<!--#include virtual="footer.html" -->
|