Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #105802 > unrolled thread

OS-X and missing file extensions

Back to article view | Back to comp.sys.mac.system

Contents

  OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-28 22:55 -0400
    Re: OS-X and missing file extensions isw <isw@witzend.com> - 2017-04-28 20:47 -0700
    Re: OS-X and missing file extensions Your Name <YourName@YourISP.com> - 2017-04-29 18:52 +1200
      Re: OS-X and missing file extensions Siri Cruise <chine.bleu@yahoo.com> - 2017-04-29 04:15 -0700
        Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-29 09:50 -0400
        Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-04-29 18:19 +0000
      Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-29 09:50 -0400
    Re: OS-X and missing file extensions dempson@actrix.gen.nz (David Empson) - 2017-04-29 23:41 +1200
      Re: OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-29 13:47 -0400
        Re: OS-X and missing file extensions Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-29 20:58 +0000
          Re: OS-X and missing file extensions Your Name <YourName@YourISP.com> - 2017-04-30 13:13 +1200
            Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-29 21:23 -0400
            Re: OS-X and missing file extensions Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-30 18:58 +0000
              Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-30 15:04 -0400
                Re: OS-X and missing file extensions android <here@there.was> - 2017-04-30 21:46 +0200
              Re: OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-30 16:35 -0400
                Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-30 16:37 -0400
                  Re: OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-30 16:43 -0400
                    Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-30 16:47 -0400
                    Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-04-30 23:11 +0000
                    Re: OS-X and missing file extensions Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-01 08:51 +0000
                      Re: OS-X and missing file extensions Your Name <YourName@YourISP.com> - 2017-05-02 11:40 +1200
                        Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-05-01 19:45 -0400
                          Re: OS-X and missing file extensions Siri Cruise <chine.bleu@yahoo.com> - 2017-05-01 19:30 -0700
                            Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-05-01 22:44 -0400
                              Re: OS-X and missing file extensions Siri Cruise <chine.bleu@yahoo.com> - 2017-05-01 20:36 -0700
                                Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-05-02 00:17 -0400
                        Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-05-01 23:47 +0000
                        Re: OS-X and missing file extensions Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-02 09:02 +0000
                Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-04-30 23:06 +0000
                Re: OS-X and missing file extensions dempson@actrix.gen.nz (David Empson) - 2017-05-01 12:43 +1200
                  Re: OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-30 23:09 -0400
                    Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-05-01 03:45 +0000
                    Re: OS-X and missing file extensions Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-01 08:56 +0000
        Re: OS-X and missing file extensions Don Bruder <Don@sonic.net> - 2017-04-30 16:16 -0700
          Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-04-30 23:47 +0000
          Re: OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-30 21:35 -0400
            Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-05-01 02:55 +0000
      Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-04-29 18:14 +0000
    Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-29 09:50 -0400
      Re: OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-29 13:50 -0400
        Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-29 13:53 -0400
        Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-04-29 18:24 +0000
          Re: OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-29 15:12 -0400
            Re: OS-X and missing file extensions nospam <nospam@nospam.invalid> - 2017-04-29 15:15 -0400
            Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-04-29 20:13 +0000
              Re: OS-X and missing file extensions JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-04-29 21:35 -0400
                Re: OS-X and missing file extensions Jolly Roger <jollyroger@pobox.com> - 2017-04-30 01:43 +0000
            Re: OS-X and missing file extensions Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-04-29 21:00 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#106042

In message <59064c5a$0$10136$c3e8da3$e408f015@news.astraweb.com> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2017-04-30 16:37, nospam wrote:

>>> > com.apple.FinderInfo:
>>> > 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00 
>>> > |AIFFSFX!.@......|

>> just what do you think  AIFFSFX!  is, if not type|creator ??

> It is a blob of 32 bytes to the file system. There isn't a type and/or
> creator fields.  Yes, everyone can see that the first 8 bytes seem to
> match the old type/creator fields, but that doesn't mean that OS-X
> treats them as such.

This will come as a shock to everyone playing along with the home game,
but you are 100% entirely absolutely wrong.

Type and Creator are still part of many files metadata and are still
used in OS X.

-- 
But just because you've seen me on your TV Doesn't mean I'm any more
enlightened than you

[toc] | [prev] | [next] | [standalone]

#106062

On 2017-05-01 08:51:32 +0000, Lewis said:

> In message <59064c5a$0$10136$c3e8da3$e408f015@news.astraweb.com> JF 
> Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>> On 2017-04-30 16:37, nospam wrote:
>>>>> 
>>>>> com.apple.FinderInfo:
>>>>> 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00
>>>>> |AIFFSFX!.@......|
>>> 
>>> just what do you think  AIFFSFX!  is, if not type|creator ??
>> 
>> It is a blob of 32 bytes to the file system. There isn't a type and/or
>> creator fields.  Yes, everyone can see that the first 8 bytes seem to
>> match the old type/creator fields, but that doesn't mean that OS-X
>> treats them as such.
> 
> This will come as a shock to everyone playing along with the home game,
> but you are 100% entirely absolutely wrong.
> 
> Type and Creator are still part of many files metadata and are still
> used in OS X.

The "metadata" at the start (sometimes end) of a data file is not a Mac 
OS type / creator code as such. It's simply part of the data file's 
standard format - it's created by any application on any operating 
system that adhere to the standards of that particular type of file.

[toc] | [prev] | [next] | [standalone]

#106063

In article <oe8h17$1a1a$1@adenine.netfront.net>, Your Name
<YourName@YourISP.com> wrote:

> 
> >>>>> com.apple.FinderInfo:
> >>>>> 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00
> >>>>> |AIFFSFX!.@......|
> >>> 
> >>> just what do you think  AIFFSFX!  is, if not type|creator ??
> >> 
> >> It is a blob of 32 bytes to the file system. There isn't a type and/or
> >> creator fields.  Yes, everyone can see that the first 8 bytes seem to
> >> match the old type/creator fields, but that doesn't mean that OS-X
> >> treats them as such.
> > 
> > This will come as a shock to everyone playing along with the home game,
> > but you are 100% entirely absolutely wrong.
> > 
> > Type and Creator are still part of many files metadata and are still
> > used in OS X.
> 
> The "metadata" at the start (sometimes end) of a data file is not a Mac 
> OS type / creator code as such. It's simply part of the data file's 
> standard format - it's created by any application on any operating 
> system that adhere to the standards of that particular type of file.

the above metadata is not part of the file's data. 

that's why it's called *metadata*.

[toc] | [prev] | [next] | [standalone]

#106065

In article <010520171945119332%nospam@nospam.invalid>,
 nospam <nospam@nospam.invalid> wrote:

> > The "metadata" at the start (sometimes end) of a data file is not a Mac 
> > OS type / creator code as such. It's simply part of the data file's 
> > standard format - it's created by any application on any operating 
> > system that adhere to the standards of that particular type of file.
> 
> the above metadata is not part of the file's data. 
> 
> that's why it's called *metadata*.

Metadata is data about data. It's anywhere it's convenient. It's the inode stat, 
it's the xattr, it's the HFS finderinfo, it's the XML file in the same 
directory, it's the TIFF tags, it's the embedded RDF, it's...well, it's whatever 
you can associate with the file that helps you process the data payload of the 
file.

> > >>>>> com.apple.FinderInfo:
> > >>>>> 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00
> > >>>>> |AIFFSFX!.@......|

If Apple has published what this xattr means, you can use that to decide whether 
what is the file and creator codes. Otherwise you can guess and hope Apple 
doesn't break your guess.

Some kinds of data have patterns in the first block which can be used to 
identify the data syntax. This is the basis of the file magic or file type in 
unix, which is different from the Mac System 9 file type. I don't believe MacOSX 
uses the unix file magic to decide the file type. It wouldn't be that hard to 
write a script that uses 'file' to derive the expected extension, especially if 
Apple publishes a list of mimetype/extension equivalences.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Free the Amos Yee one.
Yeah, too bad about your so-called life. Ha-ha.

[toc] | [prev] | [next] | [standalone]

#106067

In article
<chine.bleu-5A6DF9.19304901052017@news.eternal-september.org>, Siri
Cruise <chine.bleu@yahoo.com> wrote:

> > > The "metadata" at the start (sometimes end) of a data file is not a Mac 
> > > OS type / creator code as such. It's simply part of the data file's 
> > > standard format - it's created by any application on any operating 
> > > system that adhere to the standards of that particular type of file.
> > 
> > the above metadata is not part of the file's data. 
> > 
> > that's why it's called *metadata*.
> 
> Metadata is data about data. It's anywhere it's convenient. It's the inode
> stat, 
> it's the xattr, it's the HFS finderinfo, it's the XML file in the same 
> directory, it's the TIFF tags, it's the embedded RDF, it's...well, it's
> whatever 
> you can associate with the file that helps you process the data payload of
> the file.

file metadata is *about* the file, not part of the file itself.

> > > >>>>> com.apple.FinderInfo:
> > > >>>>> 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00
> > > >>>>> |AIFFSFX!.@......|
> 
> If Apple has published what this xattr means, you can use that to decide
> whether 
> what is the file and creator codes. Otherwise you can guess and hope Apple 
> doesn't break your guess.

there's nothing to guess.

it's a standard finder info structure, which was documented over
*thirty* *years* *ago*.

today, it can be found here (among other places):
<https://opensource.apple.com/source/xnu/xnu-344/bsd/hfs/hfs_format.h>

struct FndrFileInfo {
   u_int32_t   fdType;     /* file type */
   u_int32_t   fdCreator;  /* file creator */
   u_int16_t   fdFlags; /* Finder flags */
   struct {
       int16_t v;    /* file's location */
       int16_t h;
   } fdLocation;
   int16_t  opaque;
};
typedef struct FndrFileInfo FndrFileInfo;

> Some kinds of data have patterns in the first block which can be used to 
> identify the data syntax. This is the basis of the file magic or file type in 
> unix, which is different from the Mac System 9 file type. I don't believe
> MacOSX 
> uses the unix file magic to decide the file type. It wouldn't be that hard to 
> write a script that uses 'file' to derive the expected extension, especially if 
> Apple publishes a list of mimetype/extension equivalences.

that's a lame hack.

[toc] | [prev] | [next] | [standalone]

#106071

In article <010520172244153996%nospam@nospam.invalid>,
 nospam <nospam@nospam.invalid> wrote:

> file metadata is *about* the file, not part of the file itself.

That's going to be a surprise to anyone getting XMP from within a file instead 
of an auxillary XML file.

> > If Apple has published what this xattr means, you can use that to decide

> it's a standard finder info structure, which was documented over
> *thirty* *years* *ago*.

I don't know if Apple has promised that xattr is exactly the finderinfo. Tricky 
programmers glom onto looks like but never actually promised relations only to 
have their programs fail mysteriously years later when the promise never made is 
broken.

I already have the Inside Macintoshes.

> > write a script that uses 'file' to derive the expected extension, 
> > especially if 
> > Apple publishes a list of mimetype/extension equivalences.
> 
> that's a lame hack.

That's the pronoun game. Are you complaining about file magic, which unix has 
been using for nigh on forty years, or whether someone should fix file 
extensions?

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Free the Amos Yee one.
Yeah, too bad about your so-called life. Ha-ha.

[toc] | [prev] | [next] | [standalone]

#106072

In article
<chine.bleu-308E46.20362901052017@news.eternal-september.org>, Siri
Cruise <chine.bleu@yahoo.com> wrote:

> 
> > file metadata is *about* the file, not part of the file itself.
> 
> That's going to be a surprise to anyone getting XMP from within a file
> instead of an auxillary XML file.

which has nothing to do with finder info metadata.

> > > If Apple has published what this xattr means, you can use that to decide
> 
> > it's a standard finder info structure, which was documented over
> > *thirty* *years* *ago*.
> 
> I don't know if Apple has promised that xattr is exactly the finderinfo.

it's the same.

> Tricky 
> programmers glom onto looks like but never actually promised relations only
> to 
> have their programs fail mysteriously years later when the promise never made
> is 
> broken.
>
> I already have the Inside Macintoshes.

those are very outdated, but some stuff is still valid, including the
finfo structure, which even applied to mfs. however, fdFldr is now
opaque (and probably not used at all anymore) since mfs hasn't been
supported in a very, very long time.

volume ii, page 84:
  A file directory on a volume lists information about all the files on
  the volume. The information used by the Finder is contained in a data
  structure of type FInfo:
    TYPE FInfo = RECORD
      fdType: OSType; {file type}
      fdCreator: OSType; {file's creator}
      fdFlags: INTEGER; {flags} 
      fdLocation: Point; {file's location} 
      fdFldr: INTEGER {file's window}
    END;

> > > write a script that uses 'file' to derive the expected extension, 
> > > especially if 
> > > Apple publishes a list of mimetype/extension equivalences.
> > 
> > that's a lame hack.
> 
> That's the pronoun game. Are you complaining about file magic, which unix has 
> been using for nigh on forty years, or whether someone should fix file 
> extensions?

they're both hacks.

putting the file type into the file name (via an extension) is the very
problem that type/creator solved.

unfortunately, everyone is stuck with mistakes made 40 years ago.

[toc] | [prev] | [next] | [standalone]

#106064

On 2017-05-01, Your Name <YourName@YourISP.com> wrote:
> On 2017-05-01 08:51:32 +0000, Lewis said:
>> In message <59064c5a$0$10136$c3e8da3$e408f015@news.astraweb.com> JF 
>> Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>> On 2017-04-30 16:37, nospam wrote:
>>>>>> 
>>>>>> com.apple.FinderInfo:
>>>>>> 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00
>>>>>> |AIFFSFX!.@......|
>>>> 
>>>> just what do you think  AIFFSFX!  is, if not type|creator ??
>>> 
>>> It is a blob of 32 bytes to the file system. There isn't a type and/or
>>> creator fields.  Yes, everyone can see that the first 8 bytes seem to
>>> match the old type/creator fields, but that doesn't mean that OS-X
>>> treats them as such.
>> 
>> This will come as a shock to everyone playing along with the home game,
>> but you are 100% entirely absolutely wrong.
>> 
>> Type and Creator are still part of many files metadata and are still
>> used in OS X.
>
> The "metadata" at the start (sometimes end) of a data file

That's not what is being discussed above, silly. The creator and file
type fields in the com.apple.FinderInfo output above are extended
attributes (meta data that is *not* part of the file itself). 

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#106080

In message <oe8h17$1a1a$1@adenine.netfront.net> Your Name <YourName@YourISP.com> wrote:
> On 2017-05-01 08:51:32 +0000, Lewis said:

>> In message <59064c5a$0$10136$c3e8da3$e408f015@news.astraweb.com> JF 
>> Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>> On 2017-04-30 16:37, nospam wrote:
>>>>>> 
>>>>>> com.apple.FinderInfo:
>>>>>> 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00
>>>>>> |AIFFSFX!.@......|
>>>> 
>>>> just what do you think  AIFFSFX!  is, if not type|creator ??
>>> 
>>> It is a blob of 32 bytes to the file system. There isn't a type and/or
>>> creator fields.  Yes, everyone can see that the first 8 bytes seem to
>>> match the old type/creator fields, but that doesn't mean that OS-X
>>> treats them as such.
>> 
>> This will come as a shock to everyone playing along with the home game,
>> but you are 100% entirely absolutely wrong.
>> 
>> Type and Creator are still part of many files metadata and are still
>> used in OS X.

> The "metadata" at the start (sometimes end) of a data file is not a Mac 
> OS type / creator code as such. It's simply part of the data file's 
> standard format - it's created by any application on any operating 
> system that adhere to the standards of that particular type of file.

Some file types (MP3, JPEG, many others) will have data at the start of
the files that dscloses the type of file.

The Type and creator are not part of the file data, they are METAdata.

AIFF/SFX! is a type (AIFF) and a creator code (SFX!) which are used by
OS X and are not stored in the file.


-- 
My biggest problem is that Steve insists on serving PURPLE Kool Aid, an
I don't like PURPLE <sip sip> Kool Aid.

[toc] | [prev] | [next] | [standalone]

#105982

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2017-04-30 14:58, Lewis wrote:
> 
>> OS X did not do away with resource forks nor with type/creator fields.
>> JF, as usual, is wrong. Type?Creator have been deprecated, but they're
>> still there.
> 
> Type/Creator are not "there".

Yes they are there. And they are accessible to applications as they always
have been.

> ls  -l -@ Air\ Horn
> 
> -rwxr-xr-x@ 1 jfmezei  staff  97002 Oct 24  1991 Air Horn
>         com.apple.FinderInfo       32
> 
> 
>> xattr -l Air\ Horn 
> 
>> com.apple.FinderInfo:
>> 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00  |AIFFSFX!.@......|
>> 00000010  01 76 00 00 00 00 00 00 00 00 00 00 00 00 0A 41  |.v.............A|
>> 00000020
> 
> So there is no "file type" field as far as the OS0-F file system is
> concerned.

Nonsense. You just *think* it's different because you are using
command-line tools to look at the information.

> However, there are stubs of code that are able to look into it, if it
> exists AND there is no file extension on a file.

The same API as always.

> The application Finder also makes use of extended attributes 

As it always has.

> It looks to me far more like Apple foud a way to retrofit old style file
> information/resource forks onto a file system that does not support them
> natively. 

Nonsense. HFS is still HFS, and still supports forked files and HFS
metadata.

> There were other kludges. 

Your the only kludge here.

> But except for the Finder Aliases, I don't see "native" OS-X uses for
> old classic file attributes and resource forks.

Yeah, you wouldn't. You weren't even aware of aliases before yesterday.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#106016

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 2017-04-30 14:58, Lewis wrote:
> 
> > OS X did not do away with resource forks nor with type/creator fields.
> > JF, as usual, is wrong. Type?Creator have been deprecated, but they're
> > still there.
> 
> Type/Creator are not "there".
> 
> ls  -l -@ Air\ Horn
> 
> -rwxr-xr-x@ 1 jfmezei  staff  97002 Oct 24  1991 Air Horn
>         com.apple.FinderInfo       32
> 
> 
> > xattr -l Air\ Horn 
> 
> > com.apple.FinderInfo:
> > 00000000  41 49 46 46 53 46 58 21 01 40 FF FF FF FF 00 00  |AIFFSFX!.@......
> > |
> > 00000010  01 76 00 00 00 00 00 00 00 00 00 00 00 00 0A 41  |.v.............A
> > |
> > 00000020
> 
> So there is no "file type" field as far as the OS0-F file system is
> concerned.

Yes there is. It just isn't displayed that way by xattr.

> However, there are stubs of code that are able to look into it, if it
> exists AND there is no file extension on a file.
> 
> The application Finder also makes use of extended attributes by created
> one blob of data attached to the file which happens to be structured as
> a resource fork in which Finder stores icons and the link to the
> original file.

No. The appearance of that data as an extended attribute is an emulation
done by OS X in order to allow software using the BSD file system APIs
to access the Finder Information. In reality, on an HFS+ volume, that
data is not an extended attribute, but a block of metadata in the
directory entry.

Similarly, xattr shows a resource fork as if it was an extended
attribute, but that is also an emulation for BSD APIs.

The Carbon File Manager APIs can directly access the Finder Information
without having to go through an extended attribute emulation.

The Finder Information is NOT structured as a resource fork. The
resource fork has a completely different structure, in terms of how it
is stored on disk, linked to the directory entry, represented via
various APIs, and in its internal structure.

> The ability to do this is intertesting: ("Amadeus" is a  Finder Alias
> that points to the app).
> 
> ls -l Amadeus/..namedfork/rsrc
> -rw-r--r--  1 jfmezei  admin  62329 Nov 17  2011 Amadeus/..namedfork/rsrc
> 
> However:
> 
> ls -l Amadeus..na <tab> does NOT autocomplete. Indicating that the
> kludge to extract an extended attribute as a file isn't deep enough for
> the file system to "guide" bash to autocomplete.

The ..namedfork feature is also an emulation. It isn't a real file
system entry, so bash doesn't find it in a directory listing, therefore
autocomplete doesn't work.

HFS+ on OS X supports named forks, but the appearance of the data and
resource forks in the ..namedfork subdirectory is another emulation -
those forks don't actually have names.

> It looks to me far more like Apple foud a way to retrofit old style file
> information/resource forks onto a file system that does not support them
> natively.

No, OS X fits file system features into an API (BSD) which doesn't
support them natively.

Another one like this is the transformation of '/' in filenames on HFS+
volumes to ':' when using the BSD API. HFS+ can store '/' in filenames,
BSD cannot ('/' is a directory separator in the BSD APIs).

Conversely, UFS (available in older OS X versions) could store ':' in
filenames but not '/', so if accessing a UFS volume via Carbon File
Manager APIs, the opposite translation was needed.

> This would have been used quite a lot during the early days of
> OS-X before Snow Leopard when one could still start the Classic emulator
> to run Classic PPC apps on an Intel OS-X machine.

*Cough*. Try "before Mac OS X 10.5 Leopard when one could still start
the Classic enviroment to run classic PowerPC and 68K apps in Mac OS X
on a PowerPC Mac".

Classic was never available on Intel Macs, and was also missing from
Leopard on PowerPC Macs.

> There were other kludges. on OS-X Server (and I assume on client), the
> ftp server has the ability to handle "MacBinary" if the file extension
> is .bin and store it appropriately on the OS-X file system (creating he
> extended attributes instead of just storing a .bin blob of compressed data.

That was probably an Apple extension to the FTP server to make it
recognise MacBinary, and store the file using standard data fork,
resource fork and Finder Information.

> But except for the Finder Aliases, I don't see "native" OS-X uses for
> old classic file attributes and resource forks.

Resource forks are still used by Finder when you add a custom icon to a
file. That could be implemented as an extended attribute instead, but
Finder hasn't done that as of Sierra, probably so the icons are
recognised by older systems.

Whether Finder continues to use that method on APFS depends on how Apple
wants to deal with custom icon retention when copying files between HFS+
and APFS volumes (or vice versa) - changing the custom icon mechanism
depending on the file system would require a fair amount of data
wrangling during the copy, including digging inside a resource fork to
see what it actually contains. It is probably easier to keep using a
resource fork on APFS for custom icons.

File types are still recognised and used by Finder and Launch Services
in Sierra if there is no extension on the name.

As I already said, creator codes are ignored by Launch Services in Snow
Leopard and later.

> One aspect mentioned during the APFS presentation is HFS+ had fixed
> extended attributes and adding more was quite complex. This may explain
> why Finder chose to implement Aliases using the 2 attributes that
> already existsed as part of support for Classic.
> 
> This is why I would not be susprised if with APFS, Apple converted
> Finder aliases to "native" aliases using buil-in file attributes instead
> if hiding the fintionality in deprecated resource forks.

Aliases were traditionally implemented using resource forks, and that
form still works in Sierra, but it looks like new aliases created by
Finder in Sierra on HFS+ volumes only have a data fork. The content of
that data fork does not resemble the structure of a resource fork.

In fact, the BSD 'file' utility recognises it as a "MacOS Alias file".
Its data starts with "book<00><00><00><00>mark<00><00><00><00>". 'file'
does not recognise older aliases that use the resource fork - it thinks
they are an empty file.

I expect that this form will also be used for newly created aliases on
APFS volumes. It doubt it will use any special file attributes, other
than an easy way for the system to detect it is an alias (perhaps
continuing to use a Finder Information but as a real extended attribute,
including a file type of 'alis' and a creator of 'MACS').

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#106028

On 2017-04-30 20:43, David Empson wrote:

>> So there is no "file type" field as far as the OS0-F file system is
>> concerned.
> 
> Yes there is. It just isn't displayed that way by xattr.

The way I understand it, it si the lower Unix system which mounts disks.
Once the file system has been determined, it then attaches the
approviate software which interfaces between the Unix generic file
system semantics and the disk specific semantics. (aka: mount calls
mount_hfs).

Since an operating system kernel generally doesn't like to see higher
level software bypass it and access low level software directly, does
the Unix part of OS-X really let application APIs bypass the generic
Unix file system and talk directly to HFS in order to see the HFS disk
as a "Classic" structure and get to parsed resource froks and Finder
Info blocks?

Or do the APIs go though the Unix layer, extract the "extended
attributes", parse them and make them available to the apps if needed?


Simimarly:

if I use "vi" to create a text file. Does it end up stored on disk as a
"Classic" file complere with a 32 byte Finder Info block (empty) and a 0
byte resource fork?  (both of which are optmized away when the HFS
software translates this into Unix semantics of they are empty, and
synthetizes extended attributes of they are not).

The "Unix" way would see the APIs get extended attributes which they
would parse and transalte into Classic fields such as creator, fite type
and what not.

The "bypass" way would see the APIs get parsed "Classic" fields directly
from the HFS low level software.

But what happens if APIs bypass the Unix generaic file system when they
access a FAT32 disk ? do they also then talk in FA32 language to the
FAT32 software? or does the bypass happen only when talking to HFS
volumes, otherwise it talks via the Unix generic file system inUnix
semantics and let whatever driver for thet file system translate it into
something native for that disk ?


Finally: in terms of APIs giving applications access to parsed "Classic"
fields such as file type/creator, or access to parsed resource forks
with indiidual resources etc, is that for all APIs or only for the older
deprecated Carbon ?



> Classic was never available on Intel Macs, and was also missing from
> Leopard on PowerPC Macs.

Thanks. So I would have started at Tiger then on my G3 box,

> Finder hasn't done that as of Sierra, probably so the icons are
> recognised by older systems.

Since Sierra is still very much an HFS+ OS natively Apple couldn't have
started to evolve the old Classic HFS semantics to APFS semantics short
of rewriting the HFS software to find kludges to handle these, and that
would have made HFS volumes incompatible with older versions.

Finder appears to be a special beast, which is what I am curious on hwo
apps (normal and special like Finder) access disks in termns of software
layers.

Since APFS is an "added" file system in Sierra, I would assume that not
being native to the OS (yet), there wouldn't be special tricks possible
and likely accesse via the same layers as FAT32 or other foreign file
systems.

The APFS file system software may emulate the various structures Finder
expects to see to create aliases etc so that Finder feels at home.



> File types are still recognised and used by Finder and Launch Services
> in Sierra if there is no extension on the name.

Depending on how Finder, Launch services and other access files, it
could simply be a case of then asking "Is there a Finder Info Block for
that file" and getting a response of "NO" when the file system for that
disk doesn't support them. So the software would behave normally.

But from an "upward compatible" point of view, it would also make sense
for Apple to support all of the Classic environment file structures so
an HFS disk can be moved to APFS without any loss of data/metadata.

[toc] | [prev] | [next] | [standalone]

#106033

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2017-04-30 20:43, David Empson wrote:
> 
>>> So there is no "file type" field as far as the OS0-F file system is
>>> concerned.
>> 
>> Yes there is. It just isn't displayed that way by xattr.
> 
> The way I understand it, 

You don't understand the basics.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#106043

In message <5906a6da$0$60315$c3e8da3$66d3cc2f@news.astraweb.com> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2017-04-30 20:43, David Empson wrote:

>>> So there is no "file type" field as far as the OS0-F file system is
>>> concerned.
>> 
>> Yes there is. It just isn't displayed that way by xattr.

> The way I understand it,

You do not understand it *at* *all*; yet you continue to make up batshit
stupid things and argue about them.

-- 
"I think my [German] husband is a wee bit tired of me suggesting we
'kill us some Nazis' (with a Tennessee twang) anytime he's looking for a
plan to do something." ~Amy

[toc] | [prev] | [next] | [standalone]

#105985

In article <5904d1c8$0$61892$c3e8da3$e074e489@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:


> But I am thinking more in terms of going through the system to find
> any/all such files and try to give it an extension if one can be derived
> from the Finder Info block).

You're overcomplicating things again...

Determining whether a file is/contains an AIFF bytestream is trivial - 
The first dozen or so bytes of the file will tell you with absolute 
certainty (assuming the file hasn't been deliberately diddled to hide 
what it contains, of course) that you are or are not looking at an AIFF 
bytestream. Independent of file extension, type and/or creator codes, or 
anything else.

Figuring out exactly what you need to look for is left to you as a 
google exercise. Should take you all of about 15 seconds to find out - 
unless you're too incompetent to be allowed near a computer.

-- 
If the door is baroque don't be Haydn. Come around Bach and jiggle the Handel.

[toc] | [prev] | [next] | [standalone]

#105995

Don Bruder <Don@sonic.net> wrote:
> In article <5904d1c8$0$61892$c3e8da3$e074e489@news.astraweb.com>,
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
>> But I am thinking more in terms of going through the system to find
>> any/all such files and try to give it an extension if one can be derived
>> from the Finder Info block).
> 
> You're overcomplicating things again...
> 
> Determining whether a file is/contains an AIFF bytestream is trivial - 
> The first dozen or so bytes of the file will tell you with absolute 
> certainty (assuming the file hasn't been deliberately diddled to hide 
> what it contains, of course) that you are or are not looking at an AIFF 
> bytestream. Independent of file extension, type and/or creator codes, or 
> anything else.

Yep, and that naturally applies to many types of files.

> Figuring out exactly what you need to look for is left to you as a 
> google exercise. Should take you all of about 15 seconds to find out - 
> unless you're too incompetent to be allowed near a computer.

Good luck with that...

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#106023

On 2017-04-30 19:16, Don Bruder wrote:

> Determining whether a file is/contains an AIFF bytestream is trivial - 

The idea of preparing for a time where file type detection via old
Classic mechanism goes away is to go through all files without
extensions and handle all posisble file types, not just AIFF.

[toc] | [prev] | [next] | [standalone]

#106027

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 2017-04-30 19:16, Don Bruder wrote:
> 
>> Determining whether a file is/contains an AIFF bytestream is trivial - 
> 
> The idea of preparing for a time where file type detection via old
> Classic mechanism goes away is to go through all files without
> extensions and handle all posisble file types, not just AIFF.

What he said isn't in any way limited to AIFF files. How do you think the
"file" command-line tool works?! For god's sake, USE YOUR BRAIN AND LEARN,
DAMMIT! LEARN!!!

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#105854

David Empson <dempson@actrix.gen.nz> wrote:
> 
> I don't know offhand what support APFS has for Finder Info and resource
> forks, but at least up to macOS Sierra, Finder still supports and uses
> both features. For example, Alias files use resource forks, as do custom
> icons assigned to files.

I'm betting APFS will at least support metadata, and maybe forks too.

>> There are also copies that are empty files with the equivalent SND
>> resource in them. Are such files still openable in OS-X or would then
>> need to be imported in MacOS (Sheep Shaver edition) to be converted to
>> .AIFF) ?
> 
> OS X applications can open resource forks and the Resource Manager is
> still available (deprecated along with the rest of the Carbon API). That
> means an OS X application could access SND resources, but I don't know
> offhand of any which still support this.

Play Sound does:

<http://blache.net/software/>

> At some point, a future macOS version will drop all remaning Carbon
> support and break a lot of old applications. That hasn't happened as of
> macOS Sierra and we won't know about changes in 10.13 until WWDC.
> 
> As usual, don't leave files in old and unsupported formats if you want
> to keep accessing them into the future.

Or keep either a physical machine that will run an older version of macOS
or a virtual machine / emulator that will do it on a newer machine.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#105831

In article <59040090$0$34646$b1db1813$15bdbe48@news.astraweb.com>, JF
Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> Does Finder still look in a "resource fork" when there is no file
> extension? (I take it file extension takes precedence).

finder still uses the resource fork.

> Should I worry about this ending at some point when Finder no longer
> looks at resource forks (especially with new file system coming).  (just
> looking at a list of things to do for an upgrade).

everything ends at some point. 

apfs will need to support resource forks because a lot of existing
files have them.

> There are also copies that are empty files with the equivalent SND
> resource in them. Are such files still openable in OS-X or would then
> need to be imported in MacOS (Sheep Shaver edition) to be converted to
> .AIFF) ?

must be converted.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.mac.system

csiph-web