Re: copyPath and FilePackages
Re: copyPath and FilePackages
- Subject: Re: copyPath and FilePackages
- From: Matt Judy <email@hidden>
- Date: Wed, 12 Jun 2002 16:14:19 -0700
The Finder uses several criteria to determine if your folder is an
application bundle. First, it has to have the bundle structure, with at
least the Contents folder, the Info.plist file, and the pkgInfo file.
Then, one of two things makes it an application bundle: its name has the
.app suffix, or its HFS bundle bit is set.
If you copy an application bundle, using NSFileManager, which has a .app
suffix, it should come out just fine on the other side. It appears,
however, that the HFS bundle bit is not honored by NSFileManager, and
that any application bundle that takes this approach will lose its
apphood by way of NSFileManager.
The only solution I can offer is an unpleasant one at best, and not
really a solution at worst. Use Carbon, at least to check for the bit
before copy, and reset it after copy. Ugh.
-- Matt Judy
Lorenzo Puleo wrote:
Hi,
I used the API
ok = [[NSFileManager defaultManager] copyPath:source toPath:dest
handler:nil];
Where "source" is the application filePackage "Acrobat Reader 5.0".
I was surprised to see that, once the copy has been created, the "dest" is a
*Folder* with the same folderName and same bytes of the source. Instead it
should be a filePackage.
I run as root with MacOS X 10.1.2 on a PowerBook G3 bronze keyboard, 320MB
of RAM, and I compile with PB 1.1.1.
It's a MacOS X bug? Other filePackages like "iTunes" or "Chess" have been
copied well so the destination files are filePackages too.
If it's not a MacOS X bug, how could I detect this inconvenient and fix it?
Any assistance would be appreciated. Thanks.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.