I can think of two things. 1) the file is a sparse file with holes. 2) The file is opened for random r/w access and the filepointer is located way past the current end of the file but the file hasn't been written to yet.
Maybe another possibility is the file is opened r/w with a mmap function but due to update on access feature, the file which is treated as memory hasn't been updated due to the write on update feature which won't copy the memory until after it is written to.
A lastlog file that big is absurd, so maybe 32-bit signed offsets are used to manipulate the file, which have a 2-GB positive range, and you have found a bug somewhere.
You want to look at how in the world this file got this big. Either a bug, or maybe a denial of service attack, trying to fill up your filesystem. Maybe an attackers crude attempt to hide there tracks by making the lastlog file unreadable by increasing it size beyond what the "lastlog" command can access it. The lastlog file is binary or encrypted and so you can't simply use tail to examine it directly.
---
Update: I just checked the lastlog manpage.
Code:
The lastlog file is a database which contains info on the last login of
each user. You should not rotate it. It is a sparse file, so its size
on the disk is much smaller than the one shown by ls -l (which can
indicate a really big file if you have a high UID). You can display its
real size with ls -s.
So use "ls -s" to determine it's real size.
