site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=Fy7QqiDjwSocwj7M80wZk2tLwpdWagch7ih4QJtwnw4=; b=jGIYcBrTgJpUDlqTN0+X0opsEH/W22wdt/Gr2KmNz3TTEkc7UrdTNV6vslcbrjngmP EhfWTZU/2Ym+h63qSSMbqxoQjad2QnW1i/7XgvB1QB8yXM2Ko1OmWqySyT+Oh2DOysqa PnD6fs6ns6h9zdLj+QkWO7rn0UVQHNBpv2ez0= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=MK9D/vX+6n68X3/jnmHxS3EjVuAfjMwORZeXSsLBIh0l2rmLUXq3z+5bq8WvLZLWB7 Q4E8XrXhlm+8VDzxKKr5X26fYbb3YZKh6OVgx/w9N8E41PYZC0aQYJg3LIaS6T6FDXPV 7QveVuFILcydARgrGlQxbMpecMR4Tgz9PkRuo= On 26/06/2008, at 11:46 PM, Jean-Daniel Dupas wrote: Le 26 juin 08 à 15:29, Chris a écrit : _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I was looking for a way to figure out how long files have been in the trash, and I was hoping that stat.st_ctimespec would provide that, seeing as stat(2) says that rename(2) and link(2) will update the ctime. However this isn't the case. Renaming files doesn't affect the ctime. Is this because Darwin doesn't implement ctime, or because HFS+ doesn't implement it, or am I missing something else? Or because moving a file on HFS+ is not considere as renaming it ? On HFS+, the file name is just an other metadata (like ctime) and is not formely part of the path. Moving a file in HFS+ is just changing its parent, not its name. ctime on unix has nothing really to do with the path either, but rather the inode. Even on HFS, making another link to the file will update the ctime. In fact that is an old fashioned way of renaming on unix - link to the new path and unlink the old path (which temporarily changed the inode link count). Since BSD unix, rename is now done in the kernel rather than link/unlink, but it is still considered an event that is supposed to update the ctime. I guess HFS must have a ctime, since link(2) updates it. So wouldn't this be considered a bug? This email sent to site_archiver@lists.apple.com