Type and creator problem... system or networking? - Page 2

Craig R. Arko · 10-29-2003, 11:52 AM

Thanks, Hayne. My elaborate reply just went up in smoke when I accidentally hit Cmd-W in the browser window.

Suffice to say, many document files don't even have a resource fork. And Classic applications often are entirely a resource fork.

That's why I test stuff like the Zip compression on a copy of SimpleText.

Craig R. Arko · 10-29-2003, 12:02 PM

By the way the freeware app QuickChange will let you manage a file's TYPE/CREATOR codes in Mac OS X.

LazyMac · 10-29-2003, 12:05 PM

On a hfs+ disk, like the one in your Mac, metadata is stored apart from the file data, along with file name, last updated, etc. It's the same on a PC/unix system except that there's far less metadata.

When you save to a foreign file system (afp to a Windows server running AFP, smb to a Windows server/linux server, nfs to a unix server, a PC-formatted floppy disk, a FAT-formatted USB memory stick) the extra metadata beyond the basic name/size/updated gets bundled together with the resource fork.

The term 'resource fork' is often misused to include the custom icon, creator code etc, all of which are really metadata. But since it's all stored together in one place on foreign file systems, and we really do need a word to mean 'everthing that can't be stored in DOS/Unix metadata and data fork' I'm going to continue to misuse it.

frotoven · 10-29-2003, 03:10 PM

This is all pretty interesting.

So what is my OSX Mac doing now vis-a-vis the Win2K server that it wasn't doing before?

It sounds like this is a matter of semantics but with a real underlying difference (OK, so that means it isn't semantics)... is it relatively easy to explain?

I'm still very, very happy. OK?

mwilson · 10-29-2003, 03:18 PM

Quote:


	Originally posted by hschickel http://docs.info.apple.com/article.html?artnum=107325 Got it. I'm can see why Apple is moving to extensions and away from the current system. Thanks, Hugh

Actually, most of us can't see why Apple would want to move to an extensions-based system. If the extension controls what application opens it, what do you do with:

(a) renamed files
(b) files of the same type that you open in different apps
(c) files where you don't know the application that created it

hayne · 10-29-2003, 04:22 PM

Quote:


	Originally posted by frotoven So what is my OSX Mac doing now vis-a-vis the Win2K server that it wasn't doing before?

It's all about the protocol for communication between the two machines. if you use SMB, then when your Mac says "tell me everything you know about this file", the server doesn't tell it about the creator code since there is no place in the protocol to communicate that information.

It's analogous to sending a document by fax. The document may have coloured text in the original, but there is no way to communicate that colour over a fax link.

hschickel · 10-29-2003, 06:20 PM

Quote:


	Actually, most of us can't see why Apple would want to move to an extensions-based system. If the extension controls what application opens it, what do you do with: (a) renamed files (b) files of the same type that you open in different apps (c) files where you don't know the application that created it

I agree with you in principle - metadata is nice. I even signed a petition way back in the day to preserve it.

The way metadata is done with HFS (multiple forks) is not nice. It's difficult to play well with other systems and the legacy aspect is keeping Apple wed to HFS. By pushing bundles instead of resource forks they seem to be on a multiyear plan to dump the multi-forked file system. Applications that get upgraded to run in OSX are on a path to resource fork freedom.

I think there is a lot of hope for metadata. OSX application bundles are a neat example of a different way to deal with the issue. The user sees a single icon but the inside is filled with the metadata goodness that allows the app to run. Cocoa apps use no resource forks, they use resource folders inside the bundle instead. I believe that's also true of some Carbon apps.

It seems to me that files could be bundles in the same way. Frankly though, I'm not really sure what help that would be if 90% of the computing world uses simple extensions to track file types.

In any case, I think HFS is on it's way out. Apple has removed the need for resource forks in applications and they are pushing their developers hard to get customers to depend on extensions instead-of/in-addition-to metadata.

I've always worked in a multi-platform environment. If you're not using extensions you're not sharing files in that world. It never really bothered me. Combine the file sharing difficulties with having the file system stuck in HFS and moving or losing the metadata makes a lot more sense. I suspect improvements to the file system would proceed at a much more rapid pace if that were an open source item. At least we have journaling now.

Slow improvement is better than no improvement.

Hugh

hayne · 10-29-2003, 10:45 PM

Quote:


	Originally posted by hschickel The way metadata is done with HFS (multiple forks) is not nice.

I guess that you were speaking generally of metadata including icons etc. Because (as discussed above) the creator & type info is not stored in the resource fork - it is stored as part of the catalog info in the HFS+ filesystem.

Quote:


	In any case, I think HFS is on it's way out. Apple has removed the need for resource forks in applications and they are pushing their developers hard to get customers to depend on extensions instead-of/in-addition-to metadata.

It may well be true (unfortunately) that Apple is pushing for the use of file extensions. But that is far from saying that HFS+ is on its way out. As mentioned above, HFS+ has the capability of storing the extremely useful type & creator info without the use of any resource forks. And HFS+ has other advantages, notably speed of searching.

Quote:


	I suspect improvements to the file system would proceed at a much more rapid pace if that were an open source item.

It seems that you don't realize that HFS+ (and all the other filesystems supported by OS X) are already open source - they are part of Darwin and the source code is freely available.

darndog · 10-30-2003, 05:08 AM

After skimming the boringly long article over at Arstechnica on this subject, it would seem that the current state of affairs is a stop gap measure to ensure compatibility with other platforms. There do seem to be a lot more cons than pros after this change but as somebody mentioned earlier Apple did hire that guy who wrote the BeFS and it's hard to imagine he's peeling spuds in the Apple canteen instead of working on something new for 10.4 (Top Cat).
The unfortunate truth is that Microsoft and Linux are both moving to metadata rich file-systems, and compatibility between Mac, Windows & Linux will probably be a lot worse in 2006. dD

hschickel · 10-30-2003, 08:59 AM

HFS+ - open source - that's new to me. I think it's probably a good thing if true. As an interesting aside there are a number of reports of some new defragging code making it's way into OSX.3.

What's obvious from this thread is that I really need to go back to the drawing board to get a more thorough understanding of the difference between Finder metadata and resource forks.

For those still interested there is a wealth of information in the dev documents that seemingly points to Apple's long term transition to a single forked file system. If you follow the links please note that metadata is not disappearing - it's just moving into packages and bundles. Please keep in mind that this transition is something that I'm speculating on. Apple has made no announcement (that I'm aware of) that they are dumping HFS. This really seems to be about having options. Note the recommended practice for files is to use extensions.

Resource Forks - the Mac OSX / Carbon recommended way of dealing with the issue.

Copy / Move Operations - for those really curious there are a couple of interesting papers by Wil Sanchez floating around on the difficulties that lead to this solution.

EDIT - (for copy/move) - the original poster's problem stemmed from the fact that MS handled the metadata differently than MacOSX handled it. (See my "Got it" post above compared to the Copy / Move link here for the difference.) These inconsistencies handling the extra data are a big part of the problem (IMHO).

Finder Overview - this link is to the overview page. The embedded info is quite educational but will require some reading to get through.

Application Packages -specifics on resources and applications.

Bundles - more as above.

Hugh

hayne · 10-30-2003, 09:11 AM

Quote:


	Originally posted by hschickel HFS+ - open source - that's new to me. I think it's probably a good thing if true.

http://www.opensource.apple.com/darw...u-517/bsd/hfs/

hschickel · 10-30-2003, 09:13 AM

Nice.

Hugh

10-30-2003, 08:59 AM	#30
hschickel All Star Join Date: Jan 2002 Location: NY, NY Posts: 776	HFS+ - open source - that's new to me. I think it's probably a good thing if true. As an interesting aside there are a number of reports of some new defragging code making it's way into OSX.3. What's obvious from this thread is that I really need to go back to the drawing board to get a more thorough understanding of the difference between Finder metadata and resource forks. For those still interested there is a wealth of information in the dev documents that seemingly points to Apple's long term transition to a single forked file system. If you follow the links please note that metadata is not disappearing - it's just moving into packages and bundles. Please keep in mind that this transition is something that I'm speculating on. Apple has made no announcement (that I'm aware of) that they are dumping HFS. This really seems to be about having options. Note the recommended practice for files is to use extensions. Resource Forks - the Mac OSX / Carbon recommended way of dealing with the issue. Copy / Move Operations - for those really curious there are a couple of interesting papers by Wil Sanchez floating around on the difficulties that lead to this solution. EDIT - (for copy/move) - the original poster's problem stemmed from the fact that MS handled the metadata differently than MacOSX handled it. (See my "Got it" post above compared to the Copy / Move link here for the difference.) These inconsistencies handling the extra data are a big part of the problem (IMHO). Finder Overview - this link is to the overview page. The embedded info is quite educational but will require some reading to get through. Application Packages -specifics on resources and applications. Bundles - more as above. Hugh __________________ First they laugh at you, then they fight you, then you win. Last edited by hschickel; 10-30-2003 at 09:12 AM.

10-30-2003, 09:13 AM	#32
hschickel All Star Join Date: Jan 2002 Location: NY, NY Posts: 776	Nice. Hugh __________________ First they laugh at you, then they fight you, then you win.

10-29-2003, 11:52 AM	#21
Craig R. Arko Site Admin Join Date: Dec 2001 Location: Minneapolis, MN Posts: 3,988	Thanks, Hayne. My elaborate reply just went up in smoke when I accidentally hit Cmd-W in the browser window. Suffice to say, many document files don't even have a resource fork. And Classic applications often are entirely a resource fork. That's why I test stuff like the Zip compression on a copy of SimpleText.

10-29-2003, 12:02 PM	#22
Craig R. Arko Site Admin Join Date: Dec 2001 Location: Minneapolis, MN Posts: 3,988	By the way the freeware app QuickChange will let you manage a file's TYPE/CREATOR codes in Mac OS X.

10-29-2003, 12:05 PM	#23
LazyMac Prospect Join Date: Oct 2003 Posts: 6	On a hfs+ disk, like the one in your Mac, metadata is stored apart from the file data, along with file name, last updated, etc. It's the same on a PC/unix system except that there's far less metadata. When you save to a foreign file system (afp to a Windows server running AFP, smb to a Windows server/linux server, nfs to a unix server, a PC-formatted floppy disk, a FAT-formatted USB memory stick) the extra metadata beyond the basic name/size/updated gets bundled together with the resource fork. The term 'resource fork' is often misused to include the custom icon, creator code etc, all of which are really metadata. But since it's all stored together in one place on foreign file systems, and we really do need a word to mean 'everthing that can't be stored in DOS/Unix metadata and data fork' I'm going to continue to misuse it.

10-29-2003, 03:10 PM	#24
frotoven Prospect Join Date: Oct 2003 Posts: 7	This is all pretty interesting. So what is my OSX Mac doing now vis-a-vis the Win2K server that it wasn't doing before? It sounds like this is a matter of semantics but with a real underlying difference (OK, so that means it isn't semantics)... is it relatively easy to explain? I'm still very, very happy. OK?

10-30-2003, 05:08 AM	#29
darndog Major Leaguer Join Date: Oct 2003 Location: UK Posts: 306	After skimming the boringly long article over at Arstechnica on this subject, it would seem that the current state of affairs is a stop gap measure to ensure compatibility with other platforms. There do seem to be a lot more cons than pros after this change but as somebody mentioned earlier Apple did hire that guy who wrote the BeFS and it's hard to imagine he's peeling spuds in the Apple canteen instead of working on something new for 10.4 (Top Cat). The unfortunate truth is that Microsoft and Linux are both moving to metadata rich file-systems, and compatibility between Mac, Windows & Linux will probably be a lot worse in 2006. dD