From owner-freebsd-hackers Thu May 25 8:31:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by hub.freebsd.org (Postfix) with ESMTP id 2F85E37C5D8 for ; Thu, 25 May 2000 08:31:20 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [161.44.133.25]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA28293; Thu, 25 May 2000 11:31:17 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id LAA48025; Thu, 25 May 2000 11:31:16 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <200005251531.LAA48025@bmcgover-pc.cisco.com> To: adsharma@sharmas.dhs.org Cc: hackers@freebsd.org Subject: Re: file creation times? Date: Thu, 25 May 2000 11:31:16 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 0. I'm tired of seeing people putting "Created: mm/dd/yy" in their docuemnts. Ok, so stop them. > 1. NTFS does it. It's a part of SMB. I suspect that Samba just uses the > last modified time. Just because NTFS does it, doesn't mean its right, or even valid. See below. > 2. The average computer user would expect it. I didn't know that UNIX didn't > keep track of file creation times 5-6 years after I started using it. Well, you just proved how useless a feature it tends to be. The problem with "file creation time" is that its potentially misleading. Thats one of the reasons its called "file modification time". Take, for example, the case where someone pulls up a file, edits one word, and saves it. In those cases, the distinction between creation and modification time _may_ be remotely useful. However, given that the same user could open the file, replace the entire contents, and close it, you have to ask the question... Did they modify the file, or create a new one? The result is that there is no functional difference between deleting the old file and creating the new one, or just overwriting the old one with new data. One could argue, therefore, that the file 'creation' date is the same as the last modification date, as thats when the current contents of the file was 'created'. All-in-all, something along the lines of "inode allocated timestamp" is probably not all that useful. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message