Identifying bundles in MacOS X

[Michael J. Fromberger]

Greetings,

The following question pertains to a problem I am solving in Python
2.4b2 on a MacOS 10 (Panther) system with an HFS+ filesystem.

Given the pathname of a directory in my filesystem, I would like a
graceful way to determine whether or not that directory represents a
"bundle", in the sense that, when you double-click on the directory's
icon in the Finder, it is launched rather than "opened" for viewing.
Applications behave this way by default, but so do various other file
types (e.g., the "rtfd" files created by TextEdit, and the data files
for certain applications such as Quicken).

So, what I want is the following: A function I can call which will,
given a pathname, return True if the corresponding directory has that
property, and False otherwise. So far, I'm stumped. Can anyone help?

Here are the things I've tried so far:

I found the Carbon.File module, and tried what I thought was the obvious
thing:

from Carbon import File

fss = File.FSSpec(dir_path)
info = fss.FSpGetFInfo()

This, unfortunately, does not seem to work for directories; an OSError
is raised (-43, File Not Found). I investigated on Apple's developer
site, and it seems this is the expected behaviour. So, no fault of
Python there.

Next, I tried the following:

from Carbon import Files

fsr = File.FSRef(dir_path)
cat_info = fsr.FSGetCatalogInfo(Files.kFSCatInfoFinderInfo)

This works, but now I have no idea how to determine the answer to my
question. The value of cat_info is a tuple consisting of:

- a File.FSCatalogInfo object
- a Unicode string (the name of the directory)
- a File.FSSpec object
- a File.FSRef object

According to [1], the FSCatalogInfo structure has finderInfo and
extFinderInfo fields, which ought to contain what I'm after (I think),
but these do not appear to be exposed by the FSCatalogInfo class in the
Carbon.File library, even if I specify I want the Finder info and
extended Finder info when I call FSGetCatalogInfo().

All right, so now my questions for those of you who know better than I
do, are these:

1. Am I looking in the right place for this information?

2. If not, is there a preferred method for determining whether
a given directory represents a "bundle" in the MacOS sense?

I would be most grateful for any helpful advice you might be able to
lend me regarding this puzzle.

Thanks,
-M

P.S.- I was disconcerted to discover that the Python documentation
does not seem to list the Carbon.File module. The macfs module
is listed, but it is deprecated, so I would prefer not to use it
in new code.

References:
[1] Carbon API documentation, "FSCatalogInfo"
http://shorl.com/biginegastuni

 

[Greg Ewing]

Given the pathname of a directory in my filesystem, I would like a
graceful way to determine whether or not that directory represents a
"bundle", in the sense that, when you double-click on the directory's
icon in the Finder, it is launched rather than "opened" for viewing.
Applications behave this way by default, but so do various other file
types (e.g., the "rtfd" files created by TextEdit, and the data files
for certain applications such as Quicken).

I think that a MacOSX-style application can be recognised
simply by the fact that it's a directory whose name ends
in ".app". (You don't usually see that extension in the
Finder, but all MacOSX application bundles seem to have it.)

A Classic-style application is a file with a type code
of "APPL".

As for other files, they can be associated with applications
using either the old type/creator code system, or the new
filename-extension-based system (which is disappointingly
Windows-like, but sadly seems to be the dictated Way of
the Future :-(.)

The type and creator of a file can be found using FSpGetInfo.
You're right that this doesn't work for directories, but
directories don't have type/creator codes anyway. MacOSX
bundles seem to be recognised purely by filename suffix
(and possibly also by having the right internal structure).

 

[Michael J. Fromberger]

I think that a MacOSX-style application can be recognised simply by
the fact that it's a directory whose name ends in ".app". (You don't
usually see that extension in the Finder, but all MacOSX application
bundles seem to have it.)

Actually, Apple's developer documentation seems to imply that there is a
"bundle bit" in the Finder info (or possibly the extended Finder info)
for directories, and that if this bit is set, the Finder will treat the
folder as a bundle. At any rate, there are many bundle-like directories
other than just ".app" files and old-style 'APPL' type files. The
trouble is, the Carbon.File module does not seem to expose the
appropriate fields of the FSCatalogInfo structure from the Carbon API,
so I can't get at that bit from within Python.

I found and adapted a patch to Mac/Modules/file/_Filemodule.c, that
makes the finderInfo and finderXInfo fields visible, but either I did it
wrongly, or there is some other issue I've missed, for I get nothing but
an empty FInfo structure back when I try to access either of them.

I guess my next step should be to write a C program against the Carbon
API, and see if I can get the information that way -- if so, I guess I
will just have to patch the Carbon.File module myself. If not, I might
have to admit defeat for now.

Meanwhile, I'm using a workaround, a.k.a. a gross hack: If the
directory's name has one of a set of "known" extensions, or if it
contains a directory named "Contents", and if it doesn't have more than
a few files at its top level apart from the "Contents" directory, I'm
considering it a bundle. That works well enough for my purposes, but
I'd really rather have it work "correctly."

Thanks for taking the time to write back!

Cheers,
-M

 

[Brion Vibber]

Actually, Apple's developer documentation seems to imply that there is a
"bundle bit" in the Finder info (or possibly the extended Finder info)
for directories, and that if this bit is set, the Finder will treat the
folder as a bundle.

It's worse than that... the bundle bit _might_ or _might not_ matter,
since it's not always present, and some extensions are known or not
or... ugh.

Fortunately, it should be possible to get this information out of Launch
Services instead of replicating all the same checks: one of the flags
bit it can return is 'kLSItemInfoIsPackage'. It seems to make the
correct bundle/not bundle determination in my admittedly limited spot
checking.

I'm not sure if there's a standard Python module to expose Launch
Services, but here's a C snippet; use it as you like:

#include <Carbon/Carbon.h>
bool isFilePackage(const char *file) {
CFStringRef path = CFStringCreateWithCString(
NULL, file, kCFStringEncodingUTF8);

CFURLRef url = CFURLCreateWithFileSystemPath(
NULL, path, kCFURLPOSIXPathStyle, false);
CFRelease(path);

LSItemInfoRecord info;
LSCopyItemInfoForURL(url, kLSRequestAllInfo, &info);
CFRelease(url);

return 0 != (info.flags & kLSItemInfoIsPackage);
}

(error checking snipped for brevity)

-- brion vibber (brion @ pobox.com)

 

[Michael J. Fromberger]

It's worse than that... the bundle bit _might_ or _might not_ matter,
since it's not always present, and some extensions are known or not
or... ugh.

The plot thickens!

I'm not sure if there's a standard Python module to expose Launch
Services, but here's a C snippet; use it as you like:
[...]

Thank you very much for your advice, and for the sample code -- I will
play around with this snippet, and see I can get what I need. It looks
promising! If it works out, it will not be so difficult to add it as an
extension module.

Cheers,
-M

 

[Michael Tsai]

LSItemInfoRecord info;
LSCopyItemInfoForURL(url, kLSRequestAllInfo, &info);

I suggest using kLSRequestAllFlags instead of kLSRequestAllInfo, to
avoid leaking the strings in the LSItemInfoRecord.

--Michael

 

[Brion Vibber]

I suggest using kLSRequestAllFlags instead of kLSRequestAllInfo, to
avoid leaking the strings in the LSItemInfoRecord.

Whoops, thanks for pointing that out!

-- brion vibber (brion @ pobox.com)

 

[Greg Ewing]

It's worse than that... the bundle bit _might_ or _might not_ matter,
since it's not always present, and some extensions are known or not
or... ugh.

I get the impression that Apple are trying to move away
from reliance on finder info, resource forks, etc.,
so that MacOSX will work on non-HFS file systems.
So the bundle bit is probably regarded as a "legacy"
feature.