Slashdot Mirror
Billennium's Over - Anything Break?
An Anonymous Coward writes: "The billennium party at OpenProjects.Net rocked! Check out the log for the whole event over here. Please don't forget to use one of the mirrors. Thanks :-)" Well, anyone have anything break due to the rollover?
You could just prepend a 0 to the front of the old filenames, and it'll sort them all correctly.
See what happens when you don't use leading zeros? *grin*
Apparently there is a bug in older version of KMail from KDE 1.x that prevents KMail from correctly displaying the current date since billenium. More information about KMail billenium bug is on www.kde.org.
This was sent out to the freebsd mailing lists by John Polstra:
This morning a bug was discovered in most versions of CVSup up to and including SNAP_16_1c. The bug causes all newly-updated files to receive incorrect timestamps. Usually the files receive timestamps from early in 1970. This bug has been present for a very long time,
but it only began to have an effect when the Unix representation of the date and time passed 1,000,000,000. That occurred on 9 September
2001 at 01:46:40 UTC. Yes, other people had Y2K bugs, but I managed to produce an S1G bug.
There was more, but that was the jist.
It very much does, which brings up the point that the reason many MySQL databases suck is not due to the engine itself, but rather due to the newbies who create them.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
You could just prepend a 0 to the front of the old filenames, and it'll sort them all correctly.
t
See what happens when you don't use leading zeros? *grin*
So you'd recommend using 000000000000000000000000000000000000access_log.tx
just in case then?
Seriously though, in this case there's a known maximum size of that value, and one more 0 would have been enough (at least until we go 64bit time_t)
Jumping down to shorter values though (say 3 digit long), do you write:
23 387 96 1 12 32 43
or
023 387 096 001 012 032 043
or even
00000023 00000387 00000096 00000001 00000012 00000032 00000043
I vote for realising that you have a numeric value and splitting the int off the start and sorting by that. Bit hard in shell scripts though.
knode (0.4)
The kde news reader now orders incoming messages false. All new messages after the billenium are ordered older than the ones from before.
--
Karma 50, and all I got was this lousy T-Shirt.
Updates to Fix the CVSup 1000000000 Second Bug
http://people.freebsd.org/~jdp/s1g/
Thanks for the Log. The commentary was brilliant.
It uses strings of unix time to sort the messages in the message list by date. So after the billenium all new messages where going to the bottom..
Anyway, i've made a small fix, incase anyone wants it..
Put it in MessageList.pm line 530.
# fix for billenium, we want to be able to make sure all string that get sorted are the same length so no boo boo's happen
if (length($row[5]) == 9)
{
my $tmp = $row[5];
$row[5] = "0$tmp";
}
stuff
I haven't had time to fully investigate the cause but the software that came with my Canon S10 digital camera now claims that I took all my pictures on August the 26th (at different times though that day).
The software (is supposed) to read the time from a field in the images
The cause could be 1) The software in the camera that stores the dates in the images or 2) the photo viewing software itself. or 3) Something totally different. (Windows ?)
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
OpenLDAP has massive breakage both in the 1.2 and 2.x series with the S2G Unix time rollover.
The slurpd server completely fails to push updates from the master server to the slaves, due to string compares of timestamps in 1.2 and a related problem in 2.x. There are patches for both in OpenLDAP CVS.
The problem is detailed in the openldap-bugs mailing list -- it was extremely scary to come to work this morning and find out that all the LDAP servers had stopped pushing updates, causing account creations to fail and mail to bounce!
Nope, there are some more dates with problems prior to 2038, see this list for some of the more important ones. (I saw a more extensive list once during the pre-Y2K buildup, but those web sites have mostly disappeared. Anyone?)
"You could just prepend a 0 to the front of the old filenames, and it'll sort them all correctly."
"See what happens when you don't use leading zeros?*grin*"
Workarounds are for when you can't do it right. In this case the solution is way too simple to merit a workaround. Simply do math on scalar types, not strings. If your language doesn't know the difference never use it for anything again. If you don't know the difference, learn. Simple, see?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
My ISPs IMAP server broke. It used the maildir format and got *really* confused with file names like:
% ls -tr | tail
999878615.18243.pop.xxx.com:2,S*
999882709.76833.pop.xxx.com:2,RS*
999883989.13343.pop.xxx.com:2,S*
999900385.97510.pop.xxx.com:2,S*
999906796.21947.pop.xxx.com:2,S*
999914926.66179.pop.xxx.com:2,S*
999922220.49590.pop.xxx.com:2,S*
999975475.10798.pop.xxx.com:2,S*
1000040737.72591.pop.xxx.com:2,S*
1000062814.85554.pop.xxx.com:2,*
I think it was an old version of uw-imapd with maildir patches.
I wrote a short script to rename all files created before 1,000,000,000 with a leading zero. The resulting file names with "09*" fixed the problem!
-Dave
I would like to make your attention on bug which was introduced tonight and can affect some people who are using (var)char field to store timestamp data.
It is not worst security bug. It affects only people who already had bug in their code. Just now this bug become visible/exploitable.
This is not MySQL bug. This is how people use their database. Also similar situation can be found in other software. I would like to inform people in public list as maybe some people have to search similar problems.
The problem: Computers store time and date usually as integer value representing amount of seconds from 1 January 1970. Tonight it overrolled from 999999999 to 1000000000.
Possible bug and exploit relies on fact that some people have used character type of field to store this seconds information (we have already such case)
example:
mysql> create table session (expire varchar(100) not null);
Query OK, 0 rows affected (0.31 sec)
mysql> insert into session values (999999997), (999999998), (999999999),
(1000000000), (1000000001);
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0
mysql>
mysql> select * from session;
+------------+
| expire |
+------------+
| 999999997 |
| 999999998 |
| 999999999 |
| 1000000000 |
| 1000000001 |
+------------+
5 rows in set (0.00 sec)
mysql>
Let's assume that this table contains values we use somewhere to authenticate users. After user logs in, we write down session expiry time and later we check it like this:
mysql> select count(*) from session where expire >= '1000032535';
+----------+
| count(*) |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)
mysql>
WOW, what happened? Shouldn't be 100003253 bigger than any value in table? It worked yesterday!
In MySQL we suggested people to use quotation marks around integer values. This can avoid many web-based attacks targeted to modify SQL commands (more information on http://www.mysql.com/doc/G/e/General_security.html ). This is the reason why people put quotation marks around integer expressions and this is correct. Also automatic type casting will fix the source problem is column data is integer or some time/date vale. But when both column is character type and expression, they get compared as strings. And as we know, strings get sorted in order:
1,11,2,22
but integers:
1.2.11.22
So, this is why 100003253
It is possible that some web applicatons have endless expiry times now and not only in MySQL contexts.
Umm, no. That'd be a 31-bit number, as is the case with time_t which is a SIGNED integer. A 32-bit value can hold 2^32-1 = 4,294,967,295.
Can anyone tell me why this is a Real Problem? The obvious solution is to simply change the compilers from:
typedef long time_t;
to:
typedef unsigned long time_t;
And we can merrily keep using time_t on our 32-bit systems until 2106.
Yeah, fubar systems will break. And yeah, we'll have to change some kernel API parameter types. Cry me a river!
Veritas issued an alert that the indexing on it's backup files was broken - don't remember what it said, but basically everything would show as Jan 1, 1970 00:00:00. The datestamps were right, but the conversion routine for displaying the dates was broken. A patch that fixed the display routine fixed things up.
This space for rent. Call 1-800-STEAK4U
There's a really extensive one at http://www.merlyn.demon.co.uk/critdate.htm, by J R Stockton.
Esli epei etot cumprenan, shris soa Sfaha.
We use an older version of UW IMAP ad UW Pine both patched to use Maildir support (because they are too short-sighted to integrate such support themselves).
After the roll-over both programs started mis-sorting newly arrived messages to the top of the folder, rather than the bottom (but newly arrived messages are still sorted below older, within each category of 'before' and 'after' the 1 billion second point). Also getting 'mailbox changed unexpectedly, reloading' messages constantly.
Incase someone wants this in a bit plainer english, let me explain. (Thank you, Jesse Liberty)
:)
In C, C++, and probably most other programming languages (I'm not a guru on programming), an integer is either "signed" or "unsigned". They are also either "long" or "short". The reason for the distinctions is primarily memory-related, using a long int (4 bytes) is a waste of memory if you're just going to store say, a number up to 300 in it, in which case a short int would be more appropriate. And if you're only going to store a single byte (such as 1 or 0) there's usualy something like the int type "bool", a 1-byte long int, that allows a 1-byte value to be stored (technicaly this value could be 0 to 9, I'm not sure if negatives are allowed).
An unsigned integer is (rather obviously if you think about it) a positive-only number, you can't have a negative number in an unsigned int (well, you can try, but it'll just wrap around to its maximum value).
an unsigned long int can go from 0 to 4,294,967,295
Now, with time_t, the time is being stored in a signed long int. This can be any value from -2,147,438,648 to 2,147,483,647 (you've just split the area avalible for values between negative and positive) on a 32bit system. Unfortunitely, in 2038, that's no longer enough (DOH!) as the # of seconds from UNIX Epoch will pass the maximum (positive) value of a signed long int, and suddenly our system clocks (on POSIX-compliant, and even some/many non-compliant UNIXish systems) will wrap around to, well, the turn of the century. This is *precisely* what the fear was with Y2K, just further in the future. And this isn't theory based on a couple systems, this is a real fear, because POSIX compliant systems WILL do this. Fortunitely we have ~36 years to solve this problem.
The first solution, and probably the cleanest, is to go to 64bit systems, this transition is just beginning, but personaly I think it will be complete within 30 years... ancient business systems might still have something to worry about (as with Y2K) but I doubt it.
The other, not-as-clean-but-quick-and-simple, solution is to bump the variable holding the time to a signed long int. This could be done by a newbie with a C book, and will allow UNIX time to go to 4,294,967,295, sometime after 2100 (I think it was 2106?). This is a band-aid and doesn't really fix the end problem that what we need is an EFFICIENT dynamicaly allocated int type, but just moving to an unsigned long will buy us time if, for some reason, we haven't fixed these damn problems by 2038.
(I THINK Java has dynamic int variables, but i don't think they're efficient. I'd have to grab an extensive book on Java, and I don't have that kind of time or patience:).
And no, we can't just make infinite-sized variables in our current infrastructure, the first one that got initialized would use all the memory and lock the system
4Gigaseconds is the larges for 32bit ints. However, I'll bet 50% of the programs out there use a signed data type.. :(
You can pass a pointer to time(), and it will store the current time in the specified memory location, in addition to returning the value.
What happens when you pass an invalid pointer to the function? errno is supposed to be EFAULT, and thus time() can return -1.
In Linux, system calls directly return the errno as a negative number, and the kernel and libc reserve the first 4095 negative numbers for this purpose. Since time_t is signed, this isn't a problem. However, you would have a problem if you could not distinguish an errno return from a valid return value.
Now, forcing everyone to use gettimeofday() instead of time() would help solve this problem.
dtach - A tiny program that emulates the detach feat
one of my perl scripts that sorted some stuff via timestamp broke over the billenium because i was using "cmp" instead of "<=>". silly me.