The date is internally held as a long integer, number of seconds since "the epoch". In this case, it probably wound up being set to -1 (the epoch being Jan 1, 1970), which is completely legal, so 'fsck' feels no need to change it.
-- R; "Scully, William P" <[EMAIL PROTECTED]> Sent by: Linux on 390 Port <[email protected]> 07/17/2007 08:30 AM Please respond to Linux on 390 Port <[email protected]> From "Scully, William P" <[EMAIL PROTECTED]> To [email protected] cc Subject Wow, Now That's Reliability! Wow. The last failure was in 1969? That's reliability for you! :-) usilws30:/var/log # pwd /var/log usilws30:/var/log # ls -l faillog -rw------- 1 root root 32096 Dec 31 1969 faillog usilws30:/var/log # Hmm. On second thought perhaps the date-stamp is wrong. Anyone seen this on ext3-format disks and if so, suggestions to correct this? A file system check (via the "touch /forcefsck" technique) doesn't clean up the dates. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
