Re: cp creates directory with different permissions -- then reverts them
Re: cp creates directory with different permissions -- then reverts them
- Subject: Re: cp creates directory with different permissions -- then reverts them
- From: Quinn <email@hidden>
- Date: Tue, 31 Oct 2006 09:40:55 +0000
At 13:50 -0500 30/10/06, Michael Cashwell wrote:
One approach I've seen for this is to do the scribbling (writing,
copying, changing of permissions, etc.) somewhere hidden on the same
file system and then when that's finished move the item to the
Finder-visible location.
In general, this is the best approach. It avoids the whole issue of
the Finder seeing partial results, which makes the rest of this
discussion moot.
If this isn't possible (for example, you can't find a suitable
writable hidden location on the destination volume), there are a
bunch of things that you can do to help the Finder along:
o There are documented file types that the Finder recognises as
indicating that a file is busy. See "Finder.h".
o There is a documented creation date that does the same, also in "Finder.h".
o There is an Apple event that you can send to the Finder to request
that it syncs its view of a folder with the on-disk representation.
This is the "update" event in AppleScript. MoreAppleEvents has a
routine to send this.
<http://developer.apple.com/samplecode/MoreAppleEvents/index.html>
At 15:04 -0500 30/10/06, Dan Shoop wrote:
Which is caused by confusing the Mac Creation Date of a file with
the unix ctime, which (contrary to much misinformation) is not the
creation time of the file at all but the change time of the file,
something best associated with the Mac concept of Modification Date.
Unix doesn't have a concept of creation time.
Indeed, it doesn't. However, Mac OS X does. Take a look at the
documentation for <x-man-page://2/getattrlist>. There are 5
date/time attributes, which map to traditional UNIX and Mac OS
attributes as follows:
getattrlist stat PBGetCatInfo FSGetCatalogInfo
----------- ---- ------------ ----------------
ATTR_CMN_CRTIME st_atimespec ioFlCrDat createDate
ATTR_CMN_MODTIME st_mtimespec ioFlMdDat contentModDate
ATTR_CMN_CHGTIME st_ctimespec attributeModDate
ATTR_CMN_ACCTIME accessDate
ATTR_CMN_BKUPTIME ioFlBkDat backupDate
Traditional Mac OS creation dates and traditional UNIX ctime are
distinct attributes, and they are treated as such at the API level.
Indeed this preserving behavior for such foreign systems -- and the
preservation of Creation Date -- was long ago codified as part of
AppleDoubles.
Again, that's just not true. It's true that some volume formats do
not support creation dates. However, Mac OS X does not try to
emulate the creation dates on such volumes. For example, if you
mount a DOS/FAT volume on the Mac and view creation dates in the
Finder, you will see a column of "----".
I'd love to discuss this off-list with Apple Engineering.
If you have specific reproducible complaints (for example, "ditto"
not copying ACLs), the best thing to do is to file a bug. That's how
stuff gets fixed.
<http://developer.apple.com/bugreporter/>
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden