file type
-
Anyone have sample code for getting the file type when it's an OS9 file
with no suffix?
Cheers,
Steve
OSX freeware and shareware: http://www.dekorte.com/downloads.html -
On Saturday, Jul 12, 2003, at 17:26 America/New_York, Steve Dekorte
wrote:
>
> Anyone have sample code for getting the file type when it's an OS9
> file with no suffix?
>
Here it is in Python. It's pretty close in C, but obviously you'd have
a lot more setup and teardown.
import Carbon.File
fsspec = Carbon.File.FSSpec('somefile')
fsinfo = fsspec.FSpGetFInfo()
print fsinfo.Type
-bob -
On 7/12/03 at 2:26 PM, Steve Dekorte <steve...> wrote:
>
> Anyone have sample code for getting the file type when it's an OS9 file
> with no suffix?
>
NSDictionary * fileAttributes = [[NSFileManager defaultManager]
fileAttributesAtPath:filePath traverseLink:NO];
unsigned long code = [fileAttributes fileHFSCreatorCode];
--Eric -
On Saturday, July 12, 2003, at 3:27 PM, Eric Blair wrote:
> On 7/12/03 at 2:26 PM, Steve Dekorte <steve...> wrote:
>> Anyone have sample code for getting the file type when it's an OS9
>> file
>> with no suffix?
>>
> NSDictionary * fileAttributes = [[NSFileManager defaultManager]
> fileAttributesAtPath:filePath traverseLink:NO];
> unsigned long code = [fileAttributes fileHFSCreatorCode];
Thanks for the response.
How do I map this unsigned long to something like "JPG" or "AIF"?
Cheers,
Steve
OSX freeware and shareware: http://www.dekorte.com/downloads.html -
On 7/12/03 at 7:10 PM, Steve Dekorte <steve...> wrote:
>
> On Saturday, July 12, 2003, at 3:27 PM, Eric Blair wrote:
>> On 7/12/03 at 2:26 PM, Steve Dekorte <steve...> wrote:
>>> Anyone have sample code for getting the file type when it's an OS9
>>> file
>>> with no suffix?
>>>
>> NSDictionary * fileAttributes = [[NSFileManager defaultManager]
>> fileAttributesAtPath:filePath traverseLink:NO];
>> unsigned long code = [fileAttributes fileHFSCreatorCode];
>
> Thanks for the response.
> How do I map this unsigned long to something like "JPG" or "AIF"?
>
NSData * codeData = [NSData dataWithBytes:&code length:sizeof(code)];
NSString * codeString = [[NSString alloc]
initWithData:codeData encoding:NSMacOSRomanStringEncoding];
--Eric -
>> unsigned long code = [fileAttributes fileHFSCreatorCode];
>
> How do I map this unsigned long to something like "JPG" or "AIF"?
[NSString stringWithFormat:@"%c%c%c%c", (code >> 24), (code >> 16),
(code >> 8), code];
matt. -
On Saturday, July 12, 2003, at 7:27 PM, Eric Blair wrote:
>> How do I map this unsigned long to something like "JPG" or "AIF"?
>>
> NSData * codeData = [NSData dataWithBytes:&code
> length:sizeof(code)];
> NSString * codeString = [[NSString alloc]
> initWithData:codeData encoding:NSMacOSRomanStringEncoding];
Unfortunately, this seems to return the name of the app that created
the file, instead of the file type. In the case of image and sound
files, the same app can often create files in many different formats.
How do I actually get the file format info?
Cheers,
Steve
OSX freeware and shareware: http://www.dekorte.com/downloads.html -
On 7/13/03 at 5:21 AM, Steve Dekorte <steve...> wrote:
>Sorry, I copied the wrong line of code in the beginning of the process.
> On Saturday, July 12, 2003, at 7:27 PM, Eric Blair wrote:
>>> How do I map this unsigned long to something like "JPG" or "AIF"?
>>>
>> NSData * codeData = [NSData dataWithBytes:&code
>> length:sizeof(code)];
>> NSString * codeString = [[NSString alloc]
>> initWithData:codeData encoding:NSMacOSRomanStringEncoding];
>
> Unfortunately, this seems to return the name of the app that created
> the file, instead of the file type. In the case of image and sound
> files, the same app can often create files in many different formats.
> How do I actually get the file format info?
>
unsigned long code = [fileAttributes fileHFSTypeCode];
then run through the conversion of code to string.
You should really read the documentation for NSFileManager and NSDictionary.
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_cl
assic
/Classes/NSFileManager.html
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_cl
assic
/Classes/NSDictionary.html
NSFileManager contains the fileAttributesAtPath:traverseLink: method and
NSDictionary contains a number of helper functions for accessing the file
attributes (like fileHFSTypeCode and fileHFSCreatorCode).
--Eric -
On Sunday, Jul 13, 2003, at 08:21 America/New_York, Steve Dekorte wrote:
>
> On Saturday, July 12, 2003, at 7:27 PM, Eric Blair wrote:
>>> How do I map this unsigned long to something like "JPG" or "AIF"?
>>>
>> NSData * codeData = [NSData dataWithBytes:&code
>> length:sizeof(code)];
>> NSString * codeString = [[NSString alloc]
>> initWithData:codeData encoding:NSMacOSRomanStringEncoding];
>
> Unfortunately, this seems to return the name of the app that created
> the file, instead of the file type. In the case of image and sound
> files, the same app can often create files in many different formats.
> How do I actually get the file format info?
That's because they showed you how to get the *creator* code, not the
*type* code.
long typecode = [[[NSFileManager defaultManager]
fileAttributesAtPath:path traverseLink:YES]
objectForKey:NSFileHFSTypeCode];
NSFileHFSTypeCode may or may not have a category on NSDictionary (which
would make the code a couple characters shorter).. it's not mentioned
in the docs for NSFileManager, and I'm too lazy to look at the headers.
-bob -
On Sunday, July 13, 2003, at 9:00 AM, Shawn Erickson wrote:
> Read up on fileAttributesAtPath:traverseLink: noting what constants
> you get back, your answer is there.
Thanks Shawn. Yes, I looked at that before I posted and it wasn't clear
what "NSFileHFSTypeCode" was or what to do with the long it returned.
Seems a bit odd to store strings in longs. I guess it's OS9ism.
(hopefully one that's being phased out in OSX)
Cheers,
Steve
OSX freeware and shareware: http://www.dekorte.com/downloads.html -
On Sunday, July 13, 2003, at 02:33 PM, Steve Dekorte wrote:
>
> On Sunday, July 13, 2003, at 9:00 AM, Shawn Erickson wrote:
>> Read up on fileAttributesAtPath:traverseLink: noting what constants
>> you get back, your answer is there.
>
> Thanks Shawn. Yes, I looked at that before I posted and it wasn't
> clear what "NSFileHFSTypeCode" was or what to do with the long it
> returned. Seems a bit odd to store strings in longs. I guess it's
> OS9ism. (hopefully one that's being phased out in OSX)
Its not really intended to be a string, it is a 32b number that just
happens to have values in each byte that can be interrupted as an ASCII
character. It is designed to be compact, easily storable and comparable.
-Shawn -
On Sunday, July 13, 2003, at 2:42 PM, Shawn Erickson wrote:
> Its not really intended to be a string, it is a 32b number that just
> happens to have values in each byte that can be interrupted as an
> ASCII character. It is designed to be compact, easily storable and
> comparable.
How about portable?
Cheers,
Steve
OSX freeware and shareware: http://www.dekorte.com/downloads.html -
* On 2003.07.13, in <679B41EE-B57B-11D7-B483-000393ACB27C...>,
* "Steve Dekorte" <steve...> wrote:
>
>> Its not really intended to be a string, it is a 32b number that just
>> happens to have values in each byte that can be interrupted as an
>> ASCII character. It is designed to be compact, easily storable and
>> comparable.
>
> How about portable?
It is portable. (See the code I sent you; if you are concerned about
byte order; use the POSIX ntohl() and htonl() operations.) It's a common
approach to storing property tags in interchange file formats.
It's not particularly OS9-ish, or even Mac-ish. It's just not
specifically NeXT-ish or OSX-ish.
--
-D. <dgc...> NSIT University of Chicago
When using any driving directions or map, it's a good idea to do a
reality check and make sure the road still exists, watch out for
construction, and follow all traffic safety precautions. -
>> Its not really intended to be a string, it is a 32b number that just
>> happens to have values in each byte that can be interrupted as an
>> ASCII character. It is designed to be compact, easily storable and
>> comparable.
>
> How about portable?
'abcd' is just an integer character constant. According to the ISO C
Standard, the value of such a constant when it contains more than one
character is implementation-defined. On all Mac OS X compilers that I
know of (including GCC on Darwin/ppc and Darwin/x86), 'abcd' ==
0x61626364, so you can treat it as portably as you would any 32-bit
integer.
matt. -
On Sunday, July 13, 2003, at 3:06 PM, David Champion wrote:
> It is portable. (See the code I sent you; if you are concerned about
> byte order; use the POSIX ntohl() and htonl() operations.) It's a
> common
> approach to storing property tags in interchange file formats.
Great - can you show me some code to read this on Linux or Windows?
Cheers,
Steve
OSX freeware and shareware: http://www.dekorte.com/downloads.html -
On Sunday, July 13, 2003, at 11:56 PM, Steve Dekorte wrote:
> On Sunday, July 13, 2003, at 3:06 PM, David Champion wrote:
>> It is portable. (See the code I sent you; if you are concerned about
>> byte order; use the POSIX ntohl() and htonl() operations.) It's a
>> common
>> approach to storing property tags in interchange file formats.
> Great - can you show me some code to read this on Linux or Windows?
I think he means the concept of storing 4 character code id's which
happen to be valid ASCII characters is portable. I'm pretty sure no one
is under the impression that HFS type/creator codes are portable.
Take care,
Guy -
* On 2003.07.13, in <5FBF5D9A-B5B5-11D7-AD96-0030657160F8...>,
* "Guy English" <guy.english...> wrote:
>
> I think he means the concept of storing 4 character code id's which
> happen to be valid ASCII characters is portable. I'm pretty sure no one
> is under the impression that HFS type/creator codes are portable.
Right, the unsigned long representation is portable. The HFS internal
storage of creator/type codes -- probably not. Any *good* HFS
implementation should provide access to that one way or another, though
it's probably not portable.
Here's ANSI C code (doesn't even need POSIX!) to convert an unsigned
long containing an HFS creator or type code into a C string. (Testing,
of course, is left as an exercise to the reader.)
--
-D. <dgc...> NSIT University of Chicago
When using any driving directions or map, it's a good idea to do a
reality check and make sure the road still exists, watch out for
construction, and follow all traffic safety precautions. -
On Monday, July 14, 2003, at 03:56 pm, David Champion wrote:
> Here's ANSI C code (doesn't even need POSIX!) to convert an unsigned
> long containing an HFS creator or type code into a C string. (Testing,
> of course, is left as an exercise to the reader.)
Since there are two obvious bugs in the code as it stands, testing is
definitely not optional ;->.
(Hint: look at lines 12 and 37; the problem with line 37 isn't
technically speaking a bug in the code as is, but it would be a bug in
any non-trivial program that used these functions.)
Kind regards,
Alastair. -
* On 2003.07.14, in <09BB3A2F-B60E-11D7-90C1-000A959F5F34...>,
* "Alastair J.Houghton" <ajhoughton...> wrote:
>
> Since there are two obvious bugs in the code as it stands, testing is
> definitely not optional ;->.
>
> (Hint: look at lines 12 and 37; the problem with line 37 isn't
> technically speaking a bug in the code as is, but it would be a bug in
> any non-trivial program that used these functions.)
Fair enough. Yes, line 12's "5" should be "4". Maybe I've been working
with inferior languages too much lately.
For line 37: that's just an example of usage, neither part of the code
that was requested, nor intended as production material. But I don't
know what problem you're thinking of unless it's simply the lack of
appropriate return-value checking on the hfsTypeToCString() call.
While we're picking at my off-the-cuff code, there should be a "return
NULL;" at line 16. But really, I'm just demonstrating that the HFS
creator/type code is portable, not proposing a standard implementation
to handle it. Maybe I shouldn't post complete and functional code on
mailing lists if I don't intend to debug it. :)
--
-D. <dgc...> NSIT University of Chicago
When using any driving directions or map, it's a good idea to do a
reality check and make sure the road still exists, watch out for
construction, and follow all traffic safety precautions. -
On Monday, July 14, 2003, at 04:52 pm, David Champion wrote:
> For line 37 ... But I don't know what problem you're thinking of
> unless it's simply the lack of appropriate return-value checking on
> the hfsTypeToCString() call.
There is no call to free(). Now that's fine as long as that example is
your entire program, but it wouldn't be if you kept calling this
function (as you would in most non-trivial programs).
> While we're picking at my off-the-cuff code, there should be a "return
> NULL;" at line 16. But really, I'm just demonstrating that the HFS
> creator/type code is portable, not proposing a standard implementation
> to handle it. Maybe I shouldn't post complete and functional code on
> mailing lists if I don't intend to debug it. :)
The point I was trying to make, rather than picking at your code, was
that people shouldn't use it without testing it/checking it first :-)
The only reason that I highlighted it in this case was that both of the
bugs are problems that wouldn't be noticed by newbies and might be hard
for people (again, newbies especially) to track down.
Best regards,
Alastair.
