Re: 2 Questions
Re: 2 Questions
- Subject: Re: 2 Questions
- From: Jim Luther <email@hidden>
- Date: Mon, 13 Sep 2010 08:13:16 -0700
(oops, I accidentally sent a partial answer.)
On Sep 11, 2010, at 3:00 PM, mark wrote:
> 1) Since UTCDateTime struct is being deprecated (along with all APIs), what is going to happen to that field in FSCatalogInfo struct?
>
The FSCatalogInfo struct won't change. Deprecation does not mean that UTCDateTime is gone -- it just means that Apple no longer plans to use UTCDateTime in future API. For example, the CFURL property APIs introduced in Mac OS 10.6 use CFDate instead of UTCDateTime.
> 2) According to a document I read, node ID are manufactured for foreign file systems which do not have equivalents. If a node ID is generated for a file/directory, is it garuanteed to never change as long as the foreign file system is/remains mounted?
Since I don't know what document you read...
It depends on what you consider a node ID: The nodeID field returned by Carbon File Manager APIs, or the inode number returned by POSIX and BSD layer file system APIs (stat, lstat, getattrlist, etc).
The nodeIDs returned by Carbon File Manager APIs are unique per volume and do not change while the volume is mounted. You just have to remember that files can be moved, renamed, etc. by other processes and that can make the nodeID of a file system object at a specific location in the file system hierarchy change.
The inode number returned by POSIX and BSD layer file system APIs may or may not be unique per volume, and may change while the volume is mounted.
- Jim _______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden