Neal Becker wrote: > If I understand correctly, tar will only handle sparse files properly > if told to explicitly, using the --sparse flag. Unless tar defaults > to handling sparse intelligently without the flag, 85% of all fedora > sysadmins are going to be really pissed. Note that the -S/--sparse tar option is a GNUism. The tar you get on other systems (I checked BSD and Solaris, and the SUSv2 spec) doesn't support it, so users coming from those systems are unlikely to know the right voodoo to get a successful backup. The rsync --sparse option also seems to have had a bug tickled by this very file, so it's hard to argue that it isn't a real-world problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156809 No, this isn't a system-breaking issue (except for the case of a mildly naive user trying to backup the /var/log directory). But it's clearly undesirable and dumb. Imaging the flames if windows was discovered to have a magic file that would fill up the filesystem if you tried to copy it to a different folder. Why is this different? And the file is just ancient cruft anyway. It stores the last login time, terminal device (or X server), and remote host for each user. I found a couple of non-glibc utilities that write to the file (dhclient, useradd), but only one that actually cares to read it (lastlog(8), which can only be run by root). If this thing went away tomorrow, I doubt anyone would notice. Meaningful user login auditing is done with other tools. Are there any other clients for this file, anywhere? Note also that this is a BSD feature, and isn't part of the SUSv2 spec. In 1979 on a VAX with 16 bit UIDs, this might have been a worthwhile use of space (I found a 3BSD header that defined the lastlog struct as a 12 bytes; the current glibc structure is 292 bytes long). On a modern 64 bit linux, it leads to the 1.2TB monstrosity we're shouting about. To all the "not a bug" folks: if you were charged with deciding on a file format for storing 2 strings and a time for each user, would this honestly be your choice? Finally, note that its functionality is 100% duplicated by the wtmp file and last(1) tool anyway (except for the misfeature of not storing the user name and thus being unable to track changes in the passwd file). One could duplicate lastlog(8) using last(1) with a few lines of perl. Can we please stop the fanboy flamewars? This file is a silly side effect of the change to 32 bit UIDs, and needs to be fixed. Andy