The issue summary is "Future dates files corrupt the entries file when
commited" [sic]. The reporter found that a file had been recorded in the
"entries" file with text-time="1602-09-21T18:36:25.-291732Z" which resulted,
when Subversion tried to read it, in the error messages "svn: XML parser
failed" followed by "svn: Date conversion failed".
My analysis is:
Sometimes one encounters a file with a modification time unreasonably far in
the past or future. The cause is often unknown and is for our purposes
unimportant as we can't prevent such a file from existing.
When Subversion attempts to handle the file (adding, committing - I'm not sure
exactly what sequence of Subversion operations) the unreasonable mtime can
cause a malformed time string to be written into the "entries" file.
Subversion later chokes when trying to read the "entries" file.
Subversion doesn't have to agree to handle such a bad file, but it should avoid
getting itself into such a mess by avoiding writing a bad "entries" file.
My question is:
At what level should we handle this case?
a) When reading any file's mtime from the operating system, validate it and
throw an error (refuse to handle the file) if it is unreasonable.
b) Always preserve whatever mtime the operating system gives, ensuring that our
"entries" file can represent it, reasonable or otherwise. This might involve
the year being negative or more than four digits ... yuck.
c) Ensure that we always write a well-formed "entries" file by writing some
valid but fairly unreasonable time string instead of the totally unreasonable
mtime of the file.
I had at first been thinking (c) was the easiest way to avoid the "XML parser
failed" error, but that would only change the problem into a different one (the
recorded time stamp doesn't match the actual time stamp). Therefore I suppose
(a) is the only proper solution.
Solution (a) would involve deciding on a minimum and maximum time that we allow
(probably the year 1970 for the minimum, and perhaps the year 2100 for the
maximum), and then applying this range check either to the function(s) that
read mtime, or to the function svn_time_to_cstring() which would have to grow a
failure mode.
Agreements?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 1 21:14:28 2005