telling when a directory is really a bundle

  • According to the docs at

    http://developer.apple.com/documentation/CoreFoundation/Conceptual/
    CFBundles/Concepts/BundlesAndFinder.html#//apple_ref/doc/uid/20002127-
    BAJIBGGC

    A directory is a package if:

    1) it has a known suffix .app, .bundle, etc.
    2) it has the bundle bit set
    3) it has a known structure indicating its a bundle

    I'm trying to construct some AppleScript (from my Cocoa app) to do a
    Finder Get Info on an item.

    tell application "Finder"
    set macpath to POSIX file "%@" as text
    open information window of %@ macpath
    activate
    end tell

    I seem to need to specify "file" or "folder" in the second slot, and
    AppleScript errors if I specify folder for a bundle.

    So, given a directory, how can I tell if it is a bundle or not. I've
    tried looking at the bundle bit, but in my /Applications directory,
    only four .apps seemed to have it turn on.

    I could implement 1, 2, and 3 above myself, but that would be hacky.

    I could try and initialise a CFBundle or NSBundle with the directory,
    but that is pretty nasty too.

    Is there any easier or cleaner way to programmatically determine
    whether a directory is a bundle or not?

    If I do have to implement it myself, is there any way to get the
    "known" suffixes?
  • On 22.10.2007, at 14:35, Martin Redington wrote:
    > So, given a directory, how can I tell if it is a bundle or not.
    > I've tried looking at the bundle bit, but in my /Applications
    > directory, only four .apps seemed to have it turn on.

    NSWorkspace has an isFilePackageAtPath method... or maybe it was
    NSFileManager.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Hello,

    Am 22.10.2007 um 15:35 schrieb Martin Redington:

    > http://developer.apple.com/documentation/CoreFoundation/Conceptual/
    > CFBundles/Concepts/BundlesAndFinder.html#//apple_ref/doc/uid/
    > 20002127-BAJIBGGC
    >
    > A directory is a package if:
    >
    > 1) it has a known suffix .app, .bundle, etc.
    > 2) it has the bundle bit set
    > 3) it has a known structure indicating its a bundle

    I wonder about suffices which are known on one system but not in the
    other...

    For example, I copied an .xcodeproj bundle to a system which didn't
    have the Xcode tools installed. The Finder treated the bundle as
    ordinary folder; is this intended behaviour?

    Following the requirements list given above (and assuming the three
    requirements are AND'd), it would be correct behaviour, because
    the .xcodeproj bundle type is unknown on that system.
    Still, it would be nice if that bundled document would have been
    recognised as "some bundled document" with unknown corresponding
    application...

    Best,
    Dirk Stegemann
  • It is -[NSWorkSpace isFilePackageAtPath:], and works a treat.

        cheers,
              m.

    On 22 Oct 2007, at 13:46, Uli Kusterer wrote:

    > On 22.10.2007, at 14:35, Martin Redington wrote:
    >> So, given a directory, how can I tell if it is a bundle or not.
    >> I've tried looking at the bundle bit, but in my /Applications
    >> directory, only four .apps seemed to have it turn on.
    >
    > NSWorkspace has an isFilePackageAtPath method... or maybe it was
    > NSFileManager.
    >
    > Cheers,
    > -- M. Uli Kusterer
    > http://www.zathras.de
    >
    >
    >
    >
  • I think they're OR'd rather than AND'd - this is implied, but not
    clearly stated, in the link I referenced.

    I believe that the CFBundleDocumentTypes entry in Info.plist (which
    maps to the Document Types table in Xcode's Info for the target)
    allows you to inform the OS about new package types for your app.
    Presumably it adds these to some internal list used by the Finder at
    first launch.

    I think that the behaviour you're seeing is as intended. I haven't
    played around with the bundle bit, buts its possible that you can set
    this to get the bundle recognized as such. My quick test indicated
    that its rarely set, at least on .app's. The docs imply that its only
    valid for files in any case, which would account for that, and rule
    out it's use in your case.

    On 22 Oct 2007, at 14:19, Dirk Stegemann (Mailing-Lists) wrote:

    > Hello,
    >
    > Am 22.10.2007 um 15:35 schrieb Martin Redington:
    >
    >> http://developer.apple.com/documentation/CoreFoundation/Conceptual/
    >> CFBundles/Concepts/BundlesAndFinder.html#//apple_ref/doc/uid/
    >> 20002127-BAJIBGGC
    >>
    >> A directory is a package if:
    >>
    >> 1) it has a known suffix .app, .bundle, etc.
    >> 2) it has the bundle bit set
    >> 3) it has a known structure indicating its a bundle
    >
    > I wonder about suffices which are known on one system but not in
    > the other...
    >
    > For example, I copied an .xcodeproj bundle to a system which didn't
    > have the Xcode tools installed. The Finder treated the bundle as
    > ordinary folder; is this intended behaviour?
    >
    > Following the requirements list given above (and assuming the three
    > requirements are AND'd), it would be correct behaviour, because
    > the .xcodeproj bundle type is unknown on that system.
    > Still, it would be nice if that bundled document would have been
    > recognised as "some bundled document" with unknown corresponding
    > application...
    >
    > Best,
    > Dirk Stegemann
    >
    >
    >
    >
    >
  • On 22.10.2007, at 16:53, Martin Redington wrote:
    > I think that the behaviour you're seeing is as intended. I haven't
    > played around with the bundle bit, buts its possible that you can
    > set this to get the bundle recognized as such. My quick test
    > indicated that its rarely set, at least on .app's. The docs imply
    > that its only valid for files in any case, which would account for
    > that, and rule out it's use in your case.

      You've fallen for a misleading bit of outdated information there:

      The Bundle Bit used to indicate whether a *file* contained a BNDL
    resource (roughly equivalent to the CFBundleDocumentTypes array in
    today's Info.plists). That's why it was originally documented as only
    suitable for files.

      However, if you set it on a folder, it will there indicate that
    this folder is actually a file package, or "bundle" as it is
    sometimes called. This is a new usage introduced with OS 9, which is
    why there's still lots of docs out there that claim differently.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • I think your final implementation is likely to be using NSWorkspace,
    as others have suggested, not NSAppleScript.

    However, for the benefit of the archives, I'd like to point out that
    the construct you have below is very unsafe.

    If the path has any non-MacRoman characters in it, the AppleScript
    will fail entirely.

    If the path has QUOTES in it, then the result is undefined--the
    user's path name will end up being interpreted as AppleScript
    commands, which in the wrong hands could be used as an exploit. You
    don't want your app to be known for having a security hole :(

    The workaround is to represent the path as ‹‹utf8›› data.

    On Oct 22, 2007, at 5:35 AM, Martin Redington wrote:

    >
    > According to the docs at
    >
    > http://developer.apple.com/documentation/CoreFoundation/Conceptual/
    > CFBundles/Concepts/BundlesAndFinder.html#//apple_ref/doc/uid/
    > 20002127-BAJIBGGC
    >
    > A directory is a package if:
    >
    > 1) it has a known suffix .app, .bundle, etc.
    > 2) it has the bundle bit set
    > 3) it has a known structure indicating its a bundle
    >
    > I'm trying to construct some AppleScript (from my Cocoa app) to do
    > a Finder Get Info on an item.
    >
    > tell application "Finder"
    > set macpath to POSIX file "%@" as text
    > open information window of %@ macpath
    > activate
    > end tell
    >
    > I seem to need to specify "file" or "folder" in the second slot,
    > and AppleScript errors if I specify folder for a bundle.
    >
    > So, given a directory, how can I tell if it is a bundle or not.
    > I've tried looking at the bundle bit, but in my /Applications
    > directory, only four .apps seemed to have it turn on.
    >
    > I could implement 1, 2, and 3 above myself, but that would be hacky.
    >
    > I could try and initialise a CFBundle or NSBundle with the
    > directory, but that is pretty nasty too.
    >
    > Is there any easier or cleaner way to programmatically determine
    > whether a directory is a bundle or not?
    >
    > If I do have to implement it myself, is there any way to get the
    > "known" suffixes?
  • On Oct 22, 2007, at 5:35 AM, Martin Redington wrote:

    > A directory is a package if:
    >
    > 1) it has a known suffix .app, .bundle, etc.
    > 2) it has the bundle bit set
    > 3) it has a known structure indicating its a bundle

    I try to encourage people to distinguish between the terms "bundle"
    and "package", using "package" to refer to a directory that is
    intended to be presented to the user as a single object, and "bundle"
    to refer to a directory that is structured so as to be used with
    CFBundle/NSBundle APIs.  The two concepts are sometimes related, but
    are independent in general; for example, applications usually are
    both, frameworks usually are bundles but not packages, and RTFDs are
    packages but are not structured as bundles.  In these terms, what you
    are looking for is whether a particular directory is a package, and
    as others have noted you can use NSWorkspace (or Launch Services) to
    make this determination.

    Douglas Davidson
  • On 10/22/07 4:19 PM, Dirk Stegemann (Mailing-Lists) said:

    > For example, I copied an .xcodeproj bundle to a system which didn't
    > have the Xcode tools installed. The Finder treated the bundle as
    > ordinary folder; is this intended behaviour?

    That's because the 'bundle bit' is not set by Xcode when it saves.  In
    my experience, few applications do this, which is a shame because it's
    easy and fixes the problem you describe.

    I would suggest that all apps that save as packages/bundles set the
    bundle bit on their documents.  You can use MoreFilesX's
    FSChangeFinderFlags () function like so:

    FSChangeFinderFlags (&projFolderRef, true, kHasBundle);

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • Thanks for the tip.

    I think I'll probably write my own Get Info panel in the end, as the
    Finder one just doesn't work (by design) for too many cases
    (invisible files, etc).

    On 22 Oct 2007, at 16:30, John Stiles wrote:

    > I think your final implementation is likely to be using
    > NSWorkspace, as others have suggested, not NSAppleScript.
    >
    > However, for the benefit of the archives, I'd like to point out
    > that the construct you have below is very unsafe.
    >
    > If the path has any non-MacRoman characters in it, the AppleScript
    > will fail entirely.
    >
    > If the path has QUOTES in it, then the result is undefined--the
    > user's path name will end up being interpreted as AppleScript
    > commands, which in the wrong hands could be used as an exploit. You
    > don't want your app to be known for having a security hole :(
    >
    > The workaround is to represent the path as ‹‹utf8›› data.
    >
    > On Oct 22, 2007, at 5:35 AM, Martin Redington wrote:
    >
    >>
    >> According to the docs at
    >>
    >> http://developer.apple.com/documentation/CoreFoundation/Conceptual/
    >> CFBundles/Concepts/BundlesAndFinder.html#//apple_ref/doc/uid/
    >> 20002127-BAJIBGGC
    >>
    >> A directory is a package if:
    >>
    >> 1) it has a known suffix .app, .bundle, etc.
    >> 2) it has the bundle bit set
    >> 3) it has a known structure indicating its a bundle
    >>
    >> I'm trying to construct some AppleScript (from my Cocoa app) to do
    >> a Finder Get Info on an item.
    >>
    >> tell application "Finder"
    >> set macpath to POSIX file "%@" as text
    >> open information window of %@ macpath
    >> activate
    >> end tell
    >>
    >> I seem to need to specify "file" or "folder" in the second slot,
    >> and AppleScript errors if I specify folder for a bundle.
    >>
    >> So, given a directory, how can I tell if it is a bundle or not.
    >> I've tried looking at the bundle bit, but in my /Applications
    >> directory, only four .apps seemed to have it turn on.
    >>
    >> I could implement 1, 2, and 3 above myself, but that would be hacky.
    >>
    >> I could try and initialise a CFBundle or NSBundle with the
    >> directory, but that is pretty nasty too.
    >>
    >> Is there any easier or cleaner way to programmatically determine
    >> whether a directory is a bundle or not?
    >>
    >> If I do have to implement it myself, is there any way to get the
    >> "known" suffixes?
    >
    >
  • I'd take a look at LaunchServices.  There are a number of ways to
    identify a directory as a bundle, or its visibility, and that's one of
    the jobs of LaunchServices; to enforce these rules.

    extern OSStatus
    LSCopyItemInfoForRef(
      const FSRef *      inItemRef,
      LSRequestedInfo    inWhichInfo,
      LSItemInfoRecord *  outItemInfo)
    AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;

    LSCopyItemInfoForURL(
      CFURLRef            inURL,
      LSRequestedInfo    inWhichInfo,
      LSItemInfoRecord *  outItemInfo)
    AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;

    The LSItemInfoRecord structure returns a number of characteristics in
    the LSItemInfoFlags field.

    - Deric Horn

    On Oct 22, 2007, at 10:01 AM, Martin Redington wrote:

    >
    > Thanks for the tip.
    >
    > I think I'll probably write my own Get Info panel in the end, as the
    > Finder one just doesn't work (by design) for too many cases
    > (invisible files, etc).
    >
    >
    > On 22 Oct 2007, at 16:30, John Stiles wrote:
    >
    >> I think your final implementation is likely to be using
    >> NSWorkspace, as others have suggested, not NSAppleScript.
    >>
    >> However, for the benefit of the archives, I'd like to point out
    >> that the construct you have below is very unsafe.
    >>
    >> If the path has any non-MacRoman characters in it, the AppleScript
    >> will fail entirely.
    >>
    >> If the path has QUOTES in it, then the result is undefined--the
    >> user's path name will end up being interpreted as AppleScript
    >> commands, which in the wrong hands could be used as an exploit. You
    >> don't want your app to be known for having a security hole :(
    >>
    >> The workaround is to represent the path as ‹‹utf8›› data.
    >>
    >> On Oct 22, 2007, at 5:35 AM, Martin Redington wrote:
    >>
    >>>
    >>> According to the docs at
    >>>
    >>> http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundle
    s/Concepts/BundlesAndFinder.html#/

    >>> /apple_ref/doc/uid/20002127-BAJIBGGC
    >>>
    >>> A directory is a package if:
    >>>
    >>> 1) it has a known suffix .app, .bundle, etc.
    >>> 2) it has the bundle bit set
    >>> 3) it has a known structure indicating its a bundle
    >>>
    >>> I'm trying to construct some AppleScript (from my Cocoa app) to do
    >>> a Finder Get Info on an item.
    >>>
    >>> tell application "Finder"
    >>> set macpath to POSIX file "%@" as text
    >>> open information window of %@ macpath
    >>> activate
    >>> end tell
    >>>
    >>> I seem to need to specify "file" or "folder" in the second slot,
    >>> and AppleScript errors if I specify folder for a bundle.
    >>>
    >>> So, given a directory, how can I tell if it is a bundle or not.
    >>> I've tried looking at the bundle bit, but in my /Applications
    >>> directory, only four .apps seemed to have it turn on.
    >>>
    >>> I could implement 1, 2, and 3 above myself, but that would be hacky.
    >>>
    >>> I could try and initialise a CFBundle or NSBundle with the
    >>> directory, but that is pretty nasty too.
    >>>
    >>> Is there any easier or cleaner way to programmatically determine
    >>> whether a directory is a bundle or not?
    >>>
    >>> If I do have to implement it myself, is there any way to get the
    >>> "known" suffixes?
    >>
    >>

  • On 22 Oct 2007, at 17:44, Sean McBride wrote:

    > On 10/22/07 4:19 PM, Dirk Stegemann (Mailing-Lists) said:
    >
    >> For example, I copied an .xcodeproj bundle to a system which didn't
    >> have the Xcode tools installed. The Finder treated the bundle as
    >> ordinary folder; is this intended behaviour?
    >
    > That's because the 'bundle bit' is not set by Xcode when it saves.  In
    > my experience, few applications do this, which is a shame because it's
    > easy and fixes the problem you describe.
    >
    > I would suggest that all apps that save as packages/bundles set the
    > bundle bit on their documents.  You can use MoreFilesX's
    > FSChangeFinderFlags () function like so:
    >
    > FSChangeFinderFlags (&projFolderRef, true, kHasBundle);

    I've just been looking at the kHasCustomIcon flag, and that seems to
    be wildy inaccurate for most items as well ...

    >
    > --
    > ____________________________________________________________
    > Sean McBride, B. Eng                <sean...>
    > Rogue Research                        www.rogue-research.com
    > Mac Software Developer              Montréal, Québec, Canada
    >
    >
    >
  • On 10/22/07, Martin Redington <m.redington...> wrote:
    >
    > On 22 Oct 2007, at 17:44, Sean McBride wrote:
    >
    >> On 10/22/07 4:19 PM, Dirk Stegemann (Mailing-Lists) said:
    >>
    >>> For example, I copied an .xcodeproj bundle to a system which didn't
    >>> have the Xcode tools installed. The Finder treated the bundle as
    >>> ordinary folder; is this intended behaviour?
    >>
    >> That's because the 'bundle bit' is not set by Xcode when it saves.  In
    >> my experience, few applications do this, which is a shame because it's
    >> easy and fixes the problem you describe.
    >>
    >> I would suggest that all apps that save as packages/bundles set the
    >> bundle bit on their documents.  You can use MoreFilesX's
    >> FSChangeFinderFlags () function like so:
    >>
    >> FSChangeFinderFlags (&projFolderRef, true, kHasBundle);
    >
    > I've just been looking at the kHasCustomIcon flag, and that seems to
    > be wildy inaccurate for most items as well ...

    How so? (note that "having a custom icon" is not the same as "not
    having a generic icon")

    --
    Clark S. Cox III
    <clarkcox3...>
  • On 23 Oct 2007, at 00:39, Clark Cox wrote:

    > On 10/22/07, Martin Redington <m.redington...> wrote:
    >>
    >> On 22 Oct 2007, at 17:44, Sean McBride wrote:
    >>
    >>> On 10/22/07 4:19 PM, Dirk Stegemann (Mailing-Lists) said:
    >>>
    >>>> For example, I copied an .xcodeproj bundle to a system which didn't
    >>>> have the Xcode tools installed. The Finder treated the bundle as
    >>>> ordinary folder; is this intended behaviour?
    >>>
    >>> That's because the 'bundle bit' is not set by Xcode when it
    >>> saves.  In
    >>> my experience, few applications do this, which is a shame because
    >>> it's
    >>> easy and fixes the problem you describe.
    >>>
    >>> I would suggest that all apps that save as packages/bundles set the
    >>> bundle bit on their documents.  You can use MoreFilesX's
    >>> FSChangeFinderFlags () function like so:
    >>>
    >>> FSChangeFinderFlags (&projFolderRef, true, kHasBundle);
    >>
    >> I've just been looking at the kHasCustomIcon flag, and that seems to
    >> be wildy inaccurate for most items as well ...
    >
    > How so? (note that "having a custom icon" is not the same as "not
    > having a generic icon")

    Well, in the same way that only about four of the .app's in the /
    Applications directory has the hasBundle bit set, only a dozen had
    the kHasCustomIcon bit set.

    Without digging further, this would seem to imply that the bit is
    being set by a few creators (human or otherwise), but not
    systematically by anybody, which seems to be the situation that Sean
    outlined for hasBundle above ...
  • On 10/22/07, Martin Redington <m.redington...> wrote:
    >
    > On 23 Oct 2007, at 00:39, Clark Cox wrote:
    >
    >> On 10/22/07, Martin Redington <m.redington...> wrote:
    >>>
    >>> On 22 Oct 2007, at 17:44, Sean McBride wrote:
    >>>
    >>>> On 10/22/07 4:19 PM, Dirk Stegemann (Mailing-Lists) said:
    >>>>
    >>>>> For example, I copied an .xcodeproj bundle to a system which didn't
    >>>>> have the Xcode tools installed. The Finder treated the bundle as
    >>>>> ordinary folder; is this intended behaviour?
    >>>>
    >>>> That's because the 'bundle bit' is not set by Xcode when it
    >>>> saves.  In
    >>>> my experience, few applications do this, which is a shame because
    >>>> it's
    >>>> easy and fixes the problem you describe.
    >>>>
    >>>> I would suggest that all apps that save as packages/bundles set the
    >>>> bundle bit on their documents.  You can use MoreFilesX's
    >>>> FSChangeFinderFlags () function like so:
    >>>>
    >>>> FSChangeFinderFlags (&projFolderRef, true, kHasBundle);
    >>>
    >>> I've just been looking at the kHasCustomIcon flag, and that seems to
    >>> be wildy inaccurate for most items as well ...
    >>
    >> How so? (note that "having a custom icon" is not the same as "not
    >> having a generic icon")
    >
    > Well, in the same way that only about four of the .app's in the /
    > Applications directory has the hasBundle bit set, only a dozen had
    > the kHasCustomIcon bit set.

    Because most files don't have custom icons, they have the icons
    provided by LaunchServices.

    --
    Clark S. Cox III
    <clarkcox3...>
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today