June 2008 - Darwin-dev - lists.apple.com

Re: st_ctimespec not implemented?
by Terry Lambert 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 26 juin 08 à 15:29, Chris a écrit : <http://bugreport.apple.com> Thanks, -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Jun 26, 2008, at 3:54 PM, Chris wrote: On 27/06/2008, at 3:51 AM, Terry Lambert wrote: On Jun 26, 2008, at 7:02 AM, Chris <idou747(a)gmail.com> wrote: On 26/06/2008, at 11:46 PM, Jean-Daniel Dupas wrote: 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. Incorrect; POSIX states that the st_ctime and st_mtime of the directory that the file was renamed from/to shall be marked for update. The file itself is unchanged by the operation; it has no idea that it has been renamed. Even if POSIX is silent about ctime for the file, the Mac-OSX documentation for stat(2) is not silent, and says that the ctime should be updated. Also, all the UNIXes that I am aware of will update the ctime for rename. The documentation is wrong and the specification and current implementation is correct. Please file a bug report so that we can update the documentation. You could maybe stretch an implementation detail of HFS and claim that the btree linkages for the catalog node have been changed, and that therefore directory mtime has been changed, but that will likely not fly very far. I think its fair to say that all talk of btrees, cagalogs and other implementation details aren't really relevant to the discussion of what an API should do. You don't change an API just because some implementation detail is different. The directory ctime argument for its update on a directory change is actually predicated on another assumption that might not be valid, based on the implementation detail that "directories are files, and changing directory data is therefore changing file contents". This was true for UFS, but is not true on btree-based directories in HFS or other FSs with different implementation details. POSIX should probably update the standard to only mtime being "shall be marked for update", and ctime "may be marked for update", but it's not costing us more than a flag compare and an assignment to do both. I don't see that the cost is the primary consideration in formulating standards. All the meta-data imposes cost, but we have it because it is useful. In this case, ctime is remarkably irrelevant if rename doesn't update it. This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: st_ctimespec not implemented?
by Chris 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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=k3IVIPermjozAaQvCOEYHsAELC77YLDQ9wlaIZUx1hg=; b=mG3LMwfJwGiNkpKLrDFQsDvqPl1DNWIzFSfgWGNSe9kh38mmCdwDew32eLqs78+fk6 kdZKaKOjq1VhrbQtEiyE8/a6IiOK83OK8qKarrq9/iBGxnHd/XGa4UoekwIJ9ybA+W/9 SobZX+vKK0PWpkp4J3gLN1BuwQxNzj8jITob0= 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=Gr6nWQX/vcpnryOvLEDGkbXTM8CeBatQ8ElAt6L20bU6djuYNIwVB46eghGBDtpclV iI6XEioCFQG2pzRhVBjaoaf/+QfGaMXewx7wa0laMHIL1gL0BpCbhQcZk2iGZlgFgZ3y CGDEaUWAA+qmEiFaaCeC7PCvaL6KOkWvvFFik= On 27/06/2008, at 3:51 AM, Terry Lambert wrote: On Jun 26, 2008, at 7:02 AM, Chris <idou747(a)gmail.com> wrote: 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. Incorrect; POSIX states that the st_ctime and st_mtime of the directory that the file was renamed from/to shall be marked for update. The file itself is unchanged by the operation; it has no idea that it has been renamed. Even if POSIX is silent about ctime for the file, the Mac-OSX documentation for stat(2) is not silent, and says that the ctime should be updated. Also, all the UNIXes that I am aware of will update the ctime for rename. You could maybe stretch an implementation detail of HFS and claim that the btree linkages for the catalog node have been changed, and that therefore directory mtime has been changed, but that will likely not fly very far. I think its fair to say that all talk of btrees, cagalogs and other implementation details aren't really relevant to the discussion of what an API should do. You don't change an API just because some implementation detail is different. The directory ctime argument for its update on a directory change is actually predicated on another assumption that might not be valid, based on the implementation detail that "directories are files, and changing directory data is therefore changing file contents". This was true for UFS, but is not true on btree-based directories in HFS or other FSs with different implementation details. POSIX should probably update the standard to only mtime being "shall be marked for update", and ctime "may be marked for update", but it's not costing us more than a flag compare and an assignment to do both. I don't see that the cost is the primary consideration in formulating standards. All the meta-data imposes cost, but we have it because it is useful. In this case, ctime is remarkably irrelevant if rename doesn't update it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: st_ctimespec not implemented?
by Terry Lambert 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 26, 2008, at 7:02 AM, Chris <idou747(a)gmail.com> wrote: On 26/06/2008, at 11:46 PM, Jean-Daniel Dupas wrote: Le 26 juin 08 à 15:29, Chris a écrit : -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. Incorrect; POSIX states that the st_ctime and st_mtime of the directory that the file was renamed from/to shall be marked for update. The file itself is unchanged by the operation; it has no idea that it has been renamed. You could maybe stretch an implementation detail of HFS and claim that the btree linkages for the catalog node have been changed, and that therefore directory mtime has been changed, but that will likely not fly very far. The directory ctime argument for its update on a directory change is actually predicated on another assumption that might not be valid, based on the implementation detail that "directories are files, and changing directory data is therefore changing file contents". This was true for UFS, but is not true on btree-based directories in HFS or other FSs with different implementation details. POSIX should probably update the standard to only mtime being "shall be marked for update", and ctime "may be marked for update", but it's not costing us more than a flag compare and an assignment to do both. This email sent to site_archiver(a)lists.apple.com

1 0

Re: USB Mass Storage: command size limits
by Chris Sarcone 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: st_ctimespec not implemented?
by Jean-Daniel Dupas 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 26 juin 08 à 16:02, Chris a écrit : 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com 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? If the UNIX'03 spec says that rename should update the ctime but it does not, yes this can be probably considered as a bug. smime.p7s

1 0

Re: which set of C++ headers?
by Clark Cox 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rRKu2pfpfTYjD0MX8JZx7rKRR9Pmh+GDPNhjRvMPOkY=; b=btptoCOb/gK+9w0aar4gsDTVFLIB7jr9P2ezjQSNFHO+RKKHoQz4hZd2afrGvNcEcr mKPJ4MNmw0dbsESt4/ghtZl/0WGskGePdqFwtaSuWDBB4LjOuTraOrwsy7XwaOEfTUNb LjCf3EzS02vNmaxQf0Wst60R9iwePQgbCboZU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=B2LzcLslEka2J4/HCUiRjWIWfsvX+cLYG70lY4sV3sJ4gnzTH2VYC3RsYiLlvJC9tK vzKp+WfCWq7j8QMm15oIfuSeaauYiLIDoxF9l/2LhGJwRdw6LdgaAW9eTNRGieGe/t6k Vz3N1Rt7JGg6G1yLOrS2761sup1CEUAiaZ8KA= On Wed, Jun 25, 2008 at 6:57 PM, Alexander Agranovsky <alex(a)voxeo.com> wrote: > On Jun 25, 2008, at 8:56 PM, Clark Cox wrote: >> On Wed, Jun 25, 2008 at 3:17 PM, Alexander Agranovsky <alex(a)voxeo.com> wrote: >>> >>> Hi all, >>> >>> OSX 10.5 SDK seems to include two STL implementations -- one in >>> /Developer/SDKs/MacOSX10.5.sdk/usr/include/gcc/darwin/3.3/c++/, another >>> one >>> in /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/. >>> >>> They seem to be vastly different. So my questions are: >>> - which one is supposed to be used? >> >> You use whichever corresponds to the compiler that you're using >> >>> - what controls which one is picked? >> >> The compiler chooses (i.e. you shouldn't have to worry about it) >> > > Thanks! I figured that could be the case, but couldn't find any trace of > presence of gcc/g++ 3.3 on the system. GCC 3 is an optional install. > BTW, any idea why they're not installed as part of the toolkit, while the > headers are? That's just the way they're packaged. GCC 3 is installed in /usr/bin, while GCC 4 and later is installed in <your developer dir>/usr/bin. If the user decides to install GCC 3 later, there is no way to know *which* developer directory (remember, there can be multiple) to install the headers into. It simplifies things if the headers are installed unconditionally. -- Clark S. Cox III clarkcox3(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: st_ctimespec not implemented?
by Chris 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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(a)lists.apple.com

1 0

Re: st_ctimespec not implemented?
by Jean-Daniel Dupas 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 26 juin 08 à 15:29, Chris a écrit : Moving a file in HFS+ is just changing its parent, not its name. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com 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. smime.p7s

1 0

st_ctimespec not implemented?
by Chris 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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 :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=R5vrGwHKRCKYqKHeTxeP8aBiK7fzb6Bc5NxAh8J3YpY=; b=jgQ4HrKiNfNe0Zd4UUuTWZK200nUKo+n76Hp2Ux83zRn+YucNS3enlOctq46DPNMWC TKG1Cb12zOsIj0KntmoJqNi8ig4dknidPPv0LdMFiWCu03oAg7z/pgJfmKU7dgAX/jke k8lkkdEORRLG31Qm63kIv7hsTjqVAjnZRJAcU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=tk55I7bVn8Jk5UbXyJJw47dU+ST9VqwHsyjOBv7c+KCvu57y4ku8C92vC6kjoeP2x1 xBkZPrEfsRcwIe2FCR/mkfPUqKOCPBQBxSqeZRZXQrQP6thrqSdQpJBxmOknIrrLE/n5 H9jyP0mkVwW9CmnUWBQz2zVUG4K71odwXS60I= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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? This email sent to site_archiver(a)lists.apple.com

1 0

Re: which set of C++ headers?
by Finlay Dobbie 26 Jun '08

26 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=X1Uh4WKdLctoif8qW4ng/qmhwhtMPgqSxBlLfTwJA2c=; b=MjI0VbNc+1/vLOlLTYKAw5SJpM6NqO7jEHCKHVs6FhXIDer1jF2tB4S2LelRS1XIKR XPow/H4e/CtIyNYX6LZb12rJ+WppDxhxexzohnIuCnghIMzGZsq/8l7jraSHADQfoPI2 IVWHNHRZ/KnLbMfbffSmPIZ/n20t0DPsyb1OY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=gf/vvHIYe4kgdG8D9Dk8fbzqL830N81V0wnzHOra119F/vWUK13wRI97sXz4r8T7B0 ybsdhbO7uM/wzEa2HV0bsoXmpf0+LqNIzj2A20/9K0mxFgf0tLeOYbmaC71bqebZ3daV v+mVywpZpJ91TuT9xTlSJaCEpAVpt/LbSvMLg= On Thu, Jun 26, 2008 at 2:57 AM, Alexander Agranovsky <alex(a)voxeo.com> wrote: > Thanks! I figured that could be the case, but couldn't find any trace of > presence of gcc/g++ 3.3 on the system. They might be an optional install in Xcode Tools. > BTW, any idea why they're not installed as part of the toolkit, while the > headers are? Probably a slight mistake in packaging. -- Finlay _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0