Slashdot Mirror
The Mac, Metadata, and the World
Rick Zeman writes: "ArsTechnica has posted yet another compelling article, this time on metadata, its history and the future of metadata storage as seemingly indicated by Apple in OS X. Extensions==Bad!"
← Back to Stories (view on slashdot.org)
Metadata: A PITA for all real users!
TODO: Something witty here...
The author correalates changing the extension of a filename to the changing of the file size. I often run across files on some macintosh machines that I maintain. If I didn't have the ability to change the file type I wouldn't be able to view or edit the data. Being able to readily change the viewer/filetype lets people read things the computer doesn't know how to handle.
Bzzt Whir Click
And the glaring question was: why is Linux blindly following Windows? Linux's file type handling is still in a somewhat early stage, it wouldn't be inconceivable for the paradigm to change.
Very interesting. I never really thought about metadata before, but it brings up a lot of points about the mistake of using file extensions.
File extensions do serve a convenient purpose with a command line, as you can manipulate them easier without using multiple tools. However, if the metadata was stored outside the filename, we could have (and had) UNIX, GNU, BSD, and DOS/Windows utilities to manage them in the past. If all systems were designed to keep track of the metadata, it would have been a better world.
It is unfortunate that the technical lowest common denominator (DOS and DOS-based OSes) dictate so much of our system. While Windows NT based systems (including Win2K, WinXP, etc.) have made tremendous strides, there is a constant need to maintain compatibility that holds us back.
I think that it makes sense for Apple to adopt the file extensions, as unpleasant as they are, to support a networked world. The author's suggestion of adding them on transport makes sense, but definitely leaves something to be desired. It would be confusing to transfer Word documents around and have the extensions pop on and off depending on the environment. If the Mac leaves them alone, it still leaves something to be desired because the file name changed when it left the Mac it was created on for the file server, and when it comes back it has a different name.
It's a shame that a standard for storing the metadata wasn't created long ago. While the PCs wouldn't use the data, it is a shame to lose it. It is also a shame that we have to work towards the lowest common denominator. It's one thing to support it, it is another to adopt the conventions.
Alex
I wouldn't put it past MS if they were to take advantage of the controversy in the Mac community about the addition of file extensions in Mac OSX by getting rid of them altogether in future versions of Windows/NTFS. One of MS's true strengths lies in implementing others' (usually dated) ideas and standards in a new package with a shiny new name and/or acronym and stunning the world with a breathtaking new direction for Windows. I can see the articles now: "Windows KY Drops Need for File Extensions, Greater Control of File Naming."
Someone didn't read the article. Apple stored the file type and creator data in a dedicated metadata storage area (analogous to an inode), *not* in the resource fork. Siracusa stressed this point *several* times.
Ben "You have your mind on computers, it seems."
I think the reason Apple went to a dual file type system (extensions and metadata) is because it's too hard to implement the necessary level of interoperability otherwise. Suppose you want to keep the usual Classic MacOS method of just having file type/creator code metadata. You merrily store your files on your hard drive, with no extensions in sight.
Now you share your drive on a heterogenous network. A Win98 box connects, and looks at your files via NFS. Does the MacOS X-side NFS server automatically translate the filenames and add extensions?
Then another MacOS X user uses ssh to connect to your box. He types 'ls'. Does he see "virtual" extensions or not? What if it's a Windows user telnetting in? How would your box even know what OS the remote user was coming from?
It's just too easy to run into inconsistencies if you stick with the system of mapping file name extensions. Yes, extensions annoy me, especially since older versions of MacOS are stuck with a 31 character limit (yes, it's 31, not 32--Ars is wrong), and I have to keep file names short to be backwards compatible. Unfortunately, it's just another bad MS decision we have to live with.
Metadata in Mac OS is nifty and Microsoft tried to mimic lots of the features in Mac OS from Windows 9x onwards (associating file extensions with types and hence applications).
However, the article still seems to be just some whining Mac user who fails to understand that MOST systems in use today do not have explicit metadata describing a file's type (UNIX doesn't, do things like VMS have such metadata in the filesystem?).
In fact, for proper design, a filesystem should only be concerned with the minimum features necessary to store and retrieve data. It is up to the application and user to determine whether it makes sense to use the data in some contexts. For example, you can name files anything you want, extension or not in unix. it is up to the application to determine whether it can extract meaningful data from the file.
Oner problem with Mac OS 8.1 I have noticed is that the user cannot specify DIRECTLY which application handles a file type: it seems the application just registers itself automatically. When the application is removed/upgraded however, the associations are not updated (probably because this version of Mac OS does not really have an install/uninssall mechanism). How useful is that?
The artcile was so damn long I only read a few parts, so feel free to point out any problems.
The new code is REALLY broken, as nearly 100 posts are missing from this article now...
Scott
"Hokey religions and ancient weapons are no match for a good blaster at your side, kid."
So far, there are at least 3 fallacies in the "Fundamentals" section:
:-).
1) A file's size is not metadata: A file can best be defined as an ordered set of bytes (or bits, or words, or whatever atomic unit your system uses), and the size of that set is intrinsic to it, not external.
2) A file's modification time is conceptually unrelated to its contents. For example, most systems consider a file "modified" even when its contents are replaced by totally identical contents, and some systems provide means to change a file's contents without changing its modification time. Generally, systems use the modification time to note the time of an action that the user would see as causing a file to be modified, which is not always the same thing as noting the time that a file's content are actually changed. I know of no system that records the later time.
3) A file's type can change at will, not just to increase or decrease the "accuracy" of the typing. It's rare that a file would be useful when viewed as data of two or more independant data types, but there's nothing intrinsic in the concepts of files, their types, or metadata, to prevent this. Thus, for example, hacker can get some perverse enjoyment from writing source code that works simultaneously in multiple programming languages.
In general, the author's categorization of metadata into "immutable" and "mutable" is nonsensical. File metadata, by definition, is independent of file data, and is therefore mutable independantly of it. Sometimes systems create tighter links between metadata and data, for example when Photoshop causes files created with it to be of a certain type, or when users makes sure the names of files important to them are in uppercase, but that's a characteristic of the system (Photoshop or user conventions in these examples), not an intrinsic characteristic of data and metadata... And in the introduction, the author warns against reading the "Fundamentals" section with an eye on system implementations
I'm going to guess the author reaching beyond logic to make this categorization so as to give file typing a role distinct and more important than file naming. Needless to say, this is counter-productive.
http://www.beosbible.com/exc_filetype.html
and here:
http://www.beosbible.com/exc_query.html
The BeOS has solved the problem, years ago. The BFS has integrated all these features into the OS itself, so all applications are making use of them. The Byte.com BeOS articles from Scot Hacker are also a must read!
Unix pipes. How else are you going to get file type metadata if it isn't in-band. That is what the magic number is all about. Pipes, stdin, stdout, etc.
I think this is purely an application level problem and and not a filesystem problem.
It still matters in the gui world too. If we ever develop GUI drag and drop style graphics filters and such, say a webcam output into a filter into something else, that info is still in-band.
How would you represent the file type of a named pipe, or a socket?
In principle I dislike extensions as much as the next man, but Operating Systems everywhere manage to do a repeatedly bad job of managing the resource side of things, yes I'm talking about Window's associations and Mac resource forks (I became quite popular, at an office, some years ago, providing utilities which would strip the first 128 bits out of Mac generated Photoshop and Illustrator files).
The author of this piece even identifies the horror of allowing OSs to hide the extensions (one of the many things that gets fixed when working on a Windows machine) how could the possibility of allowing two files, in the same folder, to have the same name be acceptable, EVER!.
If there was a standard, say header, section required by all files this would be fine, but this is obviously OS dependant, remember most of that other metadata, creation date, etc etc is all stored in the FAT on most OSs. A world without extensions means that all file access would need to be pre-processed so that the correct application could subsequently be applied. Opening a file is, last time I checked, more of an overhead than examining an extension. And then what? the application police move in, preventing access to files that haven't been created in the right application?
I want more metadata about files, I want to get useful, searchable information, perhaps the real place to put it is in the file itself, like so many applications already do. Taking the responsibility away from the filename and putting it in the hands of the operating system, for encoding and decoding this metadata is fine as long as the OS doesn't break, lose the key, and remembers to enforce gatekeeping functions so that when file goes off to play in the big wide world it doesn't drag along any of that OS specific data with it.
My UID is prime!
How do you change the file type attribute on a mac?
1. funny.txt.vbs emails where
2. Hidden extensions allow Finder.app and Finder.whatever to appear as "Finder" in the same Folder....
He then goes on to say why Apple would reccomend developers use extensions (which is redundant)...A networked world demands MacOS be a better "citizen". He claims extensions are unneccisary since email apps can append extensions to files when sent...Not to mention his speculation that Apple would drop it's current model from a Windows model...
Problem with his analysis. E-mail isn't the only way to share files in OS X. Currently OS X offers FTP, HTTP, Appletalk, NFS, SSH and X.1 will add CIFS. Appletalk handles Meta information transparently, going from Mac to Mac, no need for extensions. FTP, HTTP, SSH and NFS (NFS will almost always go to a flat filesystem) offer no way to store/send OS X style meta information. Yes OS X treats a NFS drive (and CIFS drives if you use Sharity) as a UFS drive and stores Meta data properly so that the Mac can use the file, but the remote computer has NO idea what kinda of file that is, unless it has an extension. So a Mac user who casually copies a extension-less Word document to a PC zip disk, when they put that disk in a PC, it's useless (unless the user knows of the problem). So it is clear file extensions are needed for a networked enviroment....
But Mac users don't like extensions so Apple will let us hide them.... which creates the problems he described (funny.txt.vbs and duplication file names in the same folder). The first is really a non problem since the Mail application in OS X doesn't hide file extensions even if it's named funny.txt.app and double clicking the in Mail does NOT launch the file. This potential problem can be further alleviated but noting what kind of file it is below it in Mail. The second issue of duplicate file names can be solved easily too...don't allow it. In other words DumbName.jpg and DumbName.txt should not be allowed in the same folder. Then hide all the file extensions and the users would be none the wiser.
Burn Hollywood Burn
Since Slashdot was down so long, I actually had a chance to read and understand the article before posting. Perhaps there should be a pause between article posting and allowing comments? Anyway, to get on topic:
I disagree wholehartedly with the author's assessment that making the file type part of the name is a "bad thing". I disagree with his statement that the type of a file is immutable data. It is not. I have, many times, created a text file, written some html, and renamed it ".html" to load it in a web browser. Using a Mac has always been infuriating to me because I cannot easily change the application it is loaded with. It's changeable, sure, but not as easily as you can change to a simple, easily remembered mnemonic. Linux has echoed this paradigm for good reason. How hard is it to change a bash script to a different shell? Change the first line. On a Mac, this would require you to change an embedded 32 bit identifier.
The argument is bogus. slashdot.pl and slashdot.txt should NOT collide on my desktop - the type IS part of the name. The mixing of file names & types was neither a hack nor a mistake. To those of us who use computers not as an information appliance but as information builders, the ability to easily manipulate file type data is a way of life.
Thought provoking article, nonetheless.
The UNIX file-system is brilliant compared to DOS, but ONLY compared to DOS. It is still designed for command-line users convenience. I am NOT criticizing the command line, I use it daily under OpenBSD, Linux, WinNT4, Win2K, and Mac OS X. It is nice to have the control of a CLI, as well as the ability to run scripts.
HOWEVER, the system of making things conveniently obvious for the CLI results in engineering decisions that give the OS less flexibilities. GUIs can provide TREMENDOUS ammounts of information BECAUSE the user decides when to get that information.
For example, the filename and type need easy access for the user. For a GUI user, they need the filename and the type deciding the application binding. For a CLI user, including the type with the filename makes it easier to manipulate.
While you could setup ls (or dir) with many flags to pick and choose the information, you create a minor mess. Additionally, things like changing the type to a list from a database is one thing for a GUI with a dropdown box, it's a nightmare to implement in a CLI. If you designed for the CLI, you made a tradeoff.
Additionally, UNIX was developed in a hardware environment more restricted than the DOS world. Early machines used in development are nothing compared to modern machines.
Take the NTFS file system. If you are on an NT4 machine, or a Win2K machine, (running NTFS of course, not braindead FAT/FAT32) you see filenames as normal. Inside the properties, there are MANY more options. Do it on a Win2K machine, and you see more information than on an NT4 machine if you look closely.
The UNIX approach is old and dated. Microsoft has moved on, it's important for the UNIX community to do so as well. ACLs (implemented on NT) are FAR more flexible than users/groups. Private user groups are an ugly hack to handle the user/group system. The whole UNIX model needs to be modernized. There are ACL UNIX systems, but they aren't the mainstream.
I love the power of UNIX-based server, they give me tremendous capabilities. A proper CLI is awesome. But let's not kid ourselves. Beating Win95/Win98/WinME at ANYTHING was never impressive, they were ugly hacks onto DOS that has its roots in the 8086 processor. Everytime people toute the advantages of Linux, they compare it to Win9x. Beating a legacy desktop OS in terms of uptime, etc., is NOT impressive. Compared to Win2K, Linux's technical advantages are pretty minor. There are some, but not many. Compared to the BSDs or commercial UNIXes... well, Linux doesn't look that impressive. It has advantages and drawbacks, different engineering decisions.
The problem with UNIX is an LCD (lowest common denominator) and designed by committee problem. Having a common API that programmers can target is tremendous, it helps with portability. However, failing to keep moving that API foward is a mistake.
As it stands there are many applications that only work on one variant. Extending the UNIX common API once or twice a year to encompass vendor extensions would be a tremendous boost, and allow UNIX to escape this trap. If Sun has a great idea and incorporates it into Solaris, their ISVs should take advantage of it. The rest of the UNIX world should have it within a year (or two at most) so ISVs can port to other UNIXes. As it stands, you either write to an old standard OR to a particular UNIX. Neither is a good choice.
Alex
I am not very knowledgeable about this kind of thing, so maybe I am just blowing smoke here, but don't you kind of fall into an infinite loop of metadata after a while? I mean, don't need to have to know things like, say, the size of metadata. Then you have to know the size of the meta-metadata? Then you have to know the size of the metameta-metadata? How do you get around that? (I'm sure there is a simple answer, but I am scratching my head.)
"Your superior intellect is no match for our puny weapons!"
Apple's got themselves in a situation where they're struggling to be accepted in the computing world. They're over criticized - partly because people care about them.
/and/ developers, they've found a (at least mostly working) solution to make the transition.
Apple tries to appeal to the open-source community, and what happens - "Well, it's not GPL'd," or better yet: "Apple needs to open-source everything in OS X!" (and in this article there's ASCII art of masturbation... c'mon - grow up!)
They try to appeal to their own customers - and get criticized for clearing inventory fast and coming out with a better, cheaper computer (when this actually happens to everyone). More on this note: "Classic sucks" - What's Apple supposed to do? In order to survive by holding onto customers
As for the metadata - Apple's trying to stick to the more effecient use of file-typing that they have, and seems to be Ars Technica's choice, while still making it easier for interoperability along the front of other OS's.
Apple's succeeding in bringing more compatibility to their platform, and making it easier for developers to write for OS X - after all, without the programmers, Apple's f*d.
Bottom line, let's acknowledge the fact that Apple's doing what it can to survive among OS's, and not badger them about the little things (for the momment) like "extentions look too much like windows," - quit your whining.
and they think I know what I'm doing....
In a lot of ways this is a pretty good article, but there are a surprising number of instances when the author seems to have bent himself into thinking about a limited number of filesystems. Barring anything academic, experimental, or "fancy," it's pretty clear he's never tried to think about UNIX linked-list style filesystems: within the framework of his discussion, I would assert that a file's name is not part of its essential metadata in a UNIX-style FS. Why? All of the file information is contained in the file's inode and data blocks (the immediate decomposition into metadata and data being obvious). A name for the file is just an entry in a "directory," which is just another file. A given file might be listed in hundreds of different directories, nevertheless, there's still only one file. It might have a different name in each directory it's in; in which case it hardly makes sense to talk about "the filename," unless one is willing to assert that inode + data blocks don't constitute a file, and that each instance of a reference to a particular inode is to be considered a file.
/boot/vmlinuz > /dev/audio'. The results of such voluntary file polymorphism aren't always useful, but they sometimes are.
Furthermore, the examples of "immutable" metadata (ill-considered vocabulary in the first place, I think) are poorly considered. File size can be altered without altering the underlying data on BSD-style unices that provide truncation and extension system calls. Modification time often gets changed on many systems without any change to the underlying data: many, if not most, kernels will change mtime any time a file is opened for write or append even if no subsequent writes are done to the file. "File type" is essentially a nonsense notion on most UNIX filesystems (and DOS too, given the weak representation), a file's type being an interpretation an imaginary multipurpose file handler is to give the data. In such situations, "file type" is decided either by regexp matching of the file name (which can be anything, remember) and judicious use of magic (man magic if you don't get it). In many cases, this doesn't produce an unambiguous answer: 'file blah' produces 'blah: data' with amazing frequency. Arguably this just means that UNIX filesystems don't have an adequate mechanism to express the idea of "file type," but I would argue that regardless, the notion of file type is at least partially bogus. There's nothing to stop me from interpreting data many differnt ways: an XPM is something I can edit with an ordinary text editor, and hence a file of type "text," but it can also define pixmaps, so depending on what I want to do with it, it might be of at least two file types. Similarly, I can try to view a raw audio file as a compiled pixmap, or, to recapitulate the famous joke, 'cat
There are further aspects of the article which are either incorrect, or at least fail to reflect my personal experience, but for the most part it's simply repetition of previous errors. It seems abundantly clear to me that the author is a thoughtful and well-educated person whose primary computing experience has been with Macs and post-DOS MS machines: and while he may have used UNIX-like operating systems, he doesn't know much about data representation of filesystems on them, and clearly hasn't considered more modern developments like filesystems with journaling or ACLs instead of permission bits.
Perhaps my criticism is a little too sharp, I would like to emphasize that I liked much of the article and I laud the author for thinking about some important concepts in detail, but I feel the viewpoint adopted is one unnecessarily limited by the author's personal experience.
What about them? File size is independent of file contents. Of course does anybody really use sparse files these days? If I recall they had problem across filesystems way back when. Some would file the gaps with 0's and others wouldn't.
I think one of the reasons why extensions became so tightly tied to the mime-type is because of FTP. In the early days of the web, you could set up helper applications for mime-types, but if you were FTPing, you had to set it up as an extension. Now they are just linked.
-no broken link
I liked this article, it was thought provoking. It reminded me of the Archimedes, with its 16 bit file types, and the Mac. Oh, the dear Mac. How many times did I scream at it, "yes you will bloody open that file!"... While it sits there all like, "No I bloody will not, it's the wrong type, I'm not even looking at it!"... .c and .h files? What would happen if you didn't have extensions?
Hang on a minute though. It's a bit much to have a go at Microsoft about file extensions. Unix? Written in C?
Anyway. Personally I get all excited by the idea of accessing files more as a database action. I know there are people that hate the idea.
Interestingly, NTFS allows you to hang arbitrary stuff off a file. It's also a good way to hide stuff, because almost no-one knows about it. Oh, well.
A lot of things would be better if the 'lower' OSes would just pay attention to MIME types. But there's one obvious situation where it falls apart.
Joe Mac User makes an HTML document referencing a bunch of JPEG and Flash images. The JPEG and Flash files don't have extensions in their names. He sends his HTML directory to his Windows-loving friend. Assuming that the Windows or Mac apps payed attention to the file types (either Just In Time on the Mac to add extensions, or the Windows app payed attention to MIME), the user's documents would have appropriate extensions added to them. The Windows user's HTML is busted.
While it royally bites that I have to put up with extensions in OS X, I can understand why Apple did this.
You non-tech-savvy computer user (I'd think that's 80% of computer users out there), are damn clueless, and would be completely unable to fix that HTML example.
Moderators should have to take a reading comprehension test.
If I had a file that was a text file: Grocery List, which is the easiest way to display it (including a command line)...
groclist.txt
Grocery List.txt
Grocery List Text File Notepad
In the first case (old DOS 8.3 convention) you need to remember what you called it or set up a naming convention. For a grocery list, this may not matter, but for files you want to access in 8-10 years, it does.
The second is sort of clear, it is a Grocery List text file. However, you only know that it stores text.
The third provides more information. You know what it was created in, as well as the type. If you honestly think that extensions are clear to users, I think that you are mistaken. Users see icons and click, looking like a text file is a good indication.
Furthermore, nothing prevents YOU, the user, from using extensions, or dots, etc., to name you files.
For example:
Grocery List.txt Text File Notepad
OR
Grocery List.text Text File Notepad
In either case, the computer ignores the extension, using the fact that it is a Text File created in Notepad. You however, have included that with the filename for your convenience.
Alex
Linux has traditionally not bothered very much with file type. The user generally knows what to do with the file, and does so. What look like extensions are actually just generically part of the filename; there are conventions for them, but they are no more strict than the conventions for filenames in general (Makefile is probably a makefile, README is plain text, foo.c is C source, etc.).
An important thing to realize is that file type, like, for instance, size, can be determined from looking at the data. In fact, many programs look at data files and determine the file format from the data; "file" does a pretty good job of detecting non-human-readable formats, even without knowing any information at all about the file type.
Where this all breaks down, of course, is when the user wants to omit the program name. On a Mac, you normally double-click on a data file to open it (and hope to get a program that does what you want). On *nix, you traditionally have to specify the program-- and much of the time, you select a different program depending on the desired result: for foo.c, I could use emacs, or gcc, or I might want gcc -M (get dependencies), or even wc (to see how big it is), not to mention less or grep or etags.
I think part of the Mac fascination with file type is due to the monolithic program structure; you find the file, and then you open a single program that does to it anything that you will ever do to it. In this model, there is a right program, and which program is right is based on file type. Windows clearly suffers greatly from having this model but not having a more reliable fashion of determining file type than Linux.
Incidentally, has anyone else noticed that the MacOS scheme is equivalent to having 4 character extensions which aren't displayed, with the corresponding problem of having malicious executables named README.txt (or even README)?
It worked pretty well, IMO. Something similar could be done for Linux and would not need to be limited to providing metadata for the GUI. Applications would have to individually start supporting this and avoid trampling each other's metadata.
end of line
end of line
But what about users? I mean most applications are smart enough nowadays to ignore file types and simply test file formats. If I feed a text file with no extension into notepad, it doesn't reject it cause there's no .txt extension on it, and even image viewers can determine the type of image without an extension (or the incorrect extension to boot!)
I think file name extensions are more important to the user than to the applications really. If I don't need a file extension, then I don't put one. If I do, then I do. Using windows with the file types hidden drives me nutty, since I'm not heavy into GUI, the icons are meaningless to me and not shown in all applications.
Example: Programming. In a project directory there can be multiple object, source, and header files, often with similar names. The extensions serve to show ME which is which, not to tell (insert favorite text editor here) that it's trying to open an object file, C source code, or a C header file. I can make extensions that tell me which files are what just at a glance. I can feed GCC any filename I want as long as I tell it what it is.
Anyhow, just my two cents.
"If I blow your mind, you have to promise not to think in my mouth."
Yep :-)
BTW, what's going on with the BeNews server?
The author covers your foo.txt --> foo.html example when he describes how type information can be narrowed. He uses the example of the broader type of gif going to the more specific gif89a; your example is going from a text file to a specific kind of text file. The type of the file never changed: it was an html file when you created it, it was an html file when you renamed it.
You also seem to be confused about the Mac's creator codes, which simply don't exist on other operating systems. In addition to tracking the type of a file, the Mac also tracks (as meta-data) the application that created it. Does this mean a user cannot create a gif file with one application and edit it with another? Of course not. What it means is that when you double-click on a file, the application that created it will open - which is usually what the user wants. If you want to open it with another application, you open that application and then open the file.
You are right that the older Mac OS made it more difficult than it needed to be to change type and creator. But there were literally dozens of applications that filled that gap.
You are right that type is part of the name - but you seem to have missed one of the author's key points: it doesn't have to be, and probably should not.
Suppose ext4fs (some time in the future) has built in MIME types associated with every file, and an optional XML metadata piece too.
Apache gets mod'd to use the MIME types built into the files when possbile instead of using other magik.
GNOME/KDE/whatever access a database associating MIME/XML with applications.
So far, we have a great, at-least-as-good-as-Mac user experience, within the machine. Files moved by HTTP will retain the basic type. The XML could be available to those who want it by other extensions to protocol.
But, lots of things need updating. How do you "rm *.html" when things are "text/html" behind the scences? Shells need updating. New C library calls. Much of unix may need some rethought. Perl will need extensions (been done, see MacPerl).
Like the article said, FTP and Mail need updating to talk to foriegners and translate metadata to their system.
Apple may still have a chance to not botch it too. I'd like to see that.
Start Running Better Polls
Actually, I lied. I don't hate MacOS; I just wanted to get your attention by yelling about it. Now that you're here, though, I have to say that I LOVE the MacOS, and have ever since I first used it, before it was even called MacOS. I started with System 7, which was so attractive and easy to use that it's still my bar for measuring other interfaces.
.wav opens in a player, while another opens in an editor or burner. Well, I think the solution offered by Windows and by some *nix environments is better, easier, simpler, more elegant. A simple context menu, brought up by right or center-clicking, provides any options you could want. That way to open something in my viewer application, I just double-click--I know on my Windoze box that all image files (except .psd) will automatically open in my viewer, ACDSee (which recently became available for Mac, too)--no surprises, no metadata editors needed. If I want to edit it, I just right-click and choose the command "Edit" from the menu, which is set to open images with Photoshop. Same with .wav and other such--double-clicking opens in WinAMP, right-clicking and choosing "edit" opens in SoundForge. You can create any action, and choose any app to be associated with that action, for each file type--and then a list of all the possible actions for that file type will be displayed when you right-click a given file. But it will open in whatever your set to be your standard viewer, by default, if double-clicked. Much better than relying on hidden metadata. But even better and simpler than having to set up the actions and associations in the Folder Options dialog, is just using the Send To sub-menu that is brought up on right-click--just drop shortcuts to the apps you usually use into the Windows\SendTo folder, and those apps will appear on the Send To submenu when you right-click. That way I can easily open any file with any application, by using only one right-click and one left-click. In terms of launching files, it's like having the flexibility of a CLI, but within the ease-of-use of a GUI. That's one feature the Windows GUI actually got right, and got right very early on. MacOS can keep its metadata, but this is easier, simpler, better. I love the Send To submenu, though it's usually under-utilized by most people.
:-)
But if there is one thing I intensely dislike about MacOS, it's the metadata. I know I'm practically alone in the Mac camp, but I hate metadata. I have always thought it was just a space-hogging pain in my ass.
Now, the space issue is no longer a big concern since we have such big, cheap drives that a little filesystem metadata isn't such a burden on capacity. But back in the days of floppies I was pissed that I could fit so few files on a floppy when my friend with DOS could fit noticeably more. I was especially annoyed that even when I formatted a disk as a PC floppy, the Mac would still waste my space by creating and hiding from me files and folders on the disk to constiture the resource forks. I wanted every kilobyte, which counts when you're cramming a lot of small files onto a lot of small disks.
But of course this is no longer the big issue it used to be. But if I were storing large numbers of files and running out of space on a Mac, I'd still silently curse all that metadata wasting my capacity.
The part that still bothers me, now that capacity is no longer a substantial issue, is that in Windows or *nix I can instantly change file types from the interface, but not with Mac. It comes up a lot--many times a day. Click a filename, change three letters, and a text file is recognized as a script or batch file to be executed rather than opened. A click and three letters, and a file I just downloaded from USENET goes from text to UUencoded so that when I double-click it will be decoded for me. A click and three letters is all it takes to change a file's type and its application association from the GUI, without having to resort to some clunky special editor. And it's even better if I need to change the type/association of a great number of files--just open a CLI and type a quick line, and it's all done. What a pain it would be to have to use a metadata editor instead of just manipulating three letters in filenames. Simple file extensions put more power over the file within easy, simple, even automatable reach.
The advantage of metadata is something many Mac users, and theoretists like this article's author, seem to believe in, but I cannot see it. For instance, it's thought a great advantage that you can set a file to open with any application, despite the filetype. I hate downloading things on a Mac because of this. Some idjit will have a file set to open in an application I don't have, and the computer may be too stupid to know that I always open that file type in Application X. A dialog pops up on any reasonably modern MacOS to help, but it's still a big pain in the ass compared to having a PC automatically know what I open that file type with. Even more annoying is when I really do have the application the file is set to open with installed, but I always want that file type to open in a different app. This most often happens with graphics files--I do not under any circumstances want to have Photoshop or Graphic Converter open a graphics file, just because that's what it was created in. I have a simple image viewer for viewing images. If I want to edit them, *then* I open them in Photoshop. Same for Premiere and others--I do not want a big, slow editor to open my files just because that's what they were created with; we have smaller-footprint and more versatile file viewers for that.
The other part of it is that the "simplistic" (sometimes the most simple designs are the most elegant, while the more complex are just gaudy) file typing systems also solve the problem of opening certain files of a given type in one application but others of the same type in another application. Metadata proponents always point out how "great" it is to have one, for example, JPEG open in JPEGview or whatever, while another JPEG opens in Photoshop; one
I hate to say it, but the metadata folks are IMHO going the wrong way. I want more power and flexibility within my clicks, not less. I hate having to edit metadata when a simple three-letter change is all that would be needed in *nix and 'doze. And as I said, the advantages of metadata in terms of application/file association are entirely negated by the right-click menu and its Send To submenu in Windows, and similar functionality in some *nix GUIs. Metadata may have good uses, but none I can think of that can't be done more simply and elegantly. I also dislike the idea of my filesystem hiding things fom me, which unfortunately is exactly what MacOS does and what the newer NTFS in Win2k and up can do (I believe Ars had an article when Win2k came out about the new NTFS and some of the still-largely-unused metadata fields). Ext2 or FAT32 all the way, baby--and before you poo-poo FAT32, it may have almost no modern features, but it is straightforward, simple, and actually very fast in performance (thanks to the fact that it implements no real modern features); I recall it beating out NTFS in terms of raw speed in an old Ars article. Poor crash recovery is its main weakness.
I like to keep things as easy to manipulate as possible. And contrary to what many make the mistake of thinking, file extensions are not just easy for CLIs--as I said, it makes sense in a GUI too, since it can be directly manipulated from within the GUI's file browser, without having to open the file in a metadata editor. It also makes the type of file crystal-clear--especially important if you don't want to accidentally run an executable that has an icon to make it look like a file. Unless OS X has some way which I haven't noticed to visually set executables apart from other file types, even when they're on the desktop or somewhere else that doesn't show details, I can't wait for someone to create lots of OS X viruses that have common file icons. That's already a case in the Windows world, where you'll find files called Report.doc.exe that have Word icons, but if you notice the trailing extension you won't mistakenly execute them (though the "show extensions for all file types" option isn't the Windows default anyomore, alas). How can you tell by a glance in OS X, or any other place where metadata rules instead of file extensions?
Oh well. Windows may not have a lot right--but it does have its use of simple file extensions and simple context menus right. I always hated editing resource forks. It's just another *unnecessary* layer getting between a man and his hardware. Tell me one very useful thing that can be done with filesystem metadata, that can't be done easier and put more in direct control of the user. And before you say "labeling," like MacOS prior to X used to have--that's what folders/directories are for.
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
if I understood the article, file types are bad because they get in the way of allowing the user to determine how to open and view files. The only real reason to want file types is closely related to application binding, IMHO - some users want *all* html files to open in Frontpage, others want to pick and choose on a per-file basis, most want something in between.
But then why even *have* file types? You can survive quite nicely without them if you do have application binding metadata. Whenever you use an app to create a file, that file shoudl be bound to that app. If you want to subsequently open that file in a differrent app, then you shoudl let the app try. It's up to the APP, ot the filesystem, if it can open it or not. Why shoudln't you be able to open a JPG in notepad? if notepad has a hex viewing capability, it shoudl open just fine.
a well-designed app shoudl let the user attempt to open any file. It shoudl try and interpret the data correctly, and it should allow the user to bind the file to the app if they so choose.
IMHO the whole notion of file types is a mistake - the Mac approach seems to be, incorporate type as metadata, the windows approach seems to be use an extension. But neither is really necessary.
as a final note - dumping file types avoids the "identical icon" problem that the author demonstrated in the screenshot. Simply use the icon for teh file that corresponds to the *binding* , not the file type.
Don't blame me - I voted for Howard Dean. http://dean2004.blogspot.com
From the article:
Any part of the Mac OS user experience that exactly duplicates the experience on another platform ceases to be a compelling reason to buy a Mac.
I totally disagree. I had absolutely no interest in Macs until OS X, and the reason I switched was because it acts just like a *nix. I can pull up bash, run emacs, grep, sed, awk, etc. Duplicating the unix experience was a very compelling reason for me to buy a Mac. Naturally, little things like Quicktime, games, and DVD support sweetened the deal. :)
As far as metadata is concerned, I think that Mr. Siracusa is right. The current unix way of handling metadata sucks. Unfortunately, the future does not lie with the old "Mac Way", which is arguably a good deal more elegant. Steve Jobs knows this, which is why his new OS is based on unix, despite its' occasional warts (like file extensions). Apple has done what it had to do to survive in this new world. I just hope that a lot of the old Mac partisans will stop trying to cling to the past and join us for the ride.
This
It's Really Easy (tm). You can either use ResEdit, an unsupported 68k application that Apple has all but disowned, or use some third-party utility.
That's right. You need third-party software to change the file type on a Mac, and even then it's not easy. While Windows maintains a correlation between filenames and descriptions (.doc = Microsoft Word Document, for example) there is no such listing in Mac OS. True power users are just supposed to know that MSWD is a Word document.
For more information, click here.
The author mentions that in CoreServices, two different Finders appear. /System/Library/CoreServices with terminal.app, I can see that one is simple called "Finder", the other is called "Finder.app". Changing my Finder view to "table" I can see that one is a "Application"; the other, a "Classic Application." So there are ways to differentiate the files-- though neither is quite elegant. The extensions are probably necessary for Nextstep compatibility.
.ps extension for Distiller is just plain rude), the immutability of the Creator/Type codes, save for ResEdit, is someaht inconvenient. I remember writing Applescript applications to change these codes en mass. Not exactly user friendly.
Checking my
In Windows 95 & and successors, the GUI hides the extensions, and as the author points out, this can cause serious problems with vbs viruses. But what was left unmentioned is that it also is hard on programmers. If you can't tell the difference at a glance between "myclass.h" and "myclass.cpp", it really cramps your coding style...
Microsoft also hides files that end in ".dll"-- which is a pain if you program libaries. This is somewhat more defensible, but not by much.
Truth be told, although certain aspects of the Type/Creator code were far more elegant than enaything Windows 9X ever developed (Note to Adobe-- grabbing the
These did the trick.
On HPFS, they were stored as part of the file in the filesystem. You could copy the file to a FAT formatted floppy, however, and the EA's were stored as a separate file, allowing you to keep all attributes, including the long file name.
Before /. went kablooey earlier today, someone pointed out that BeOS used MIME for identifying file types.
As for the MIME example you give above, it is as much the job of Windows to add (or ignore) the extension to a MIME'd file as it is for Apple to add the proper extension. In other words, I'd say it's the Windows machine's fault for not recognizing the file for what it was, just as much as it was the Apple's fault for not adding the extension. Interoperability requires both sides.
> I know I'm practically alone in the Mac camp, but I hate metadata.
I know a lot of Mac users(including me) who feel the same way. I think the metadata lovers are just a lot more vocal.
On Mac OS X it's a little different, though. The "Types Change" plugin isn't available (yet?). But the "Open Using" plugin isn't really necessary, since you can force-open any file by dragging to an app in the dock while holding down command and option. Hopefully there will be a way to change the type and creator of a file on X soon, and all will be back to normal.
Free Hans!
Phew, that article was long-winded. And 5 pages later, we finally discover the argument he was building up to. File extensions are evil, windows is kludgy, and OSX sucks.
Having not played with OSX, I have no opinion about it one way or another. Criticizing windows is easy, and many many people have beaten that dead horse over the years.
Which leads us to the last point he was trying to make, which is we should all get rid of file extensions. I'd like to ask him, what glorious benefit would we get from removing file extensions in all OS's in exchange for all the disruption it would cause, just to satisfy his sense of aesthetics? I'm not saying it's a bad thing, but geez, there are bigger problems out there to solve than this. This is the equivalent of arguing over whether the turn signal stalk on the steering column should also contain a rotating knob on the end for wiper blade control.
Who cares!?
Sounds like the rantings of another Macolyte, trying to convince the rest of us that he's better than us. You might be right, but the world stopped caring long ago.
What I do have a problem with is the splintered way that MIME is done in practice. Suppose I want my file type "foo" to be associated with a certain mime type and opened with my fooviewer, I would have to register my application/x-foo in:
/usr/share/mimelnk/application/x-foo.kdelnk
/usr/share/applnk/Multimedia/fooviewer.kdelnk
/usr/share/mime-info/fooviewer.keys
/usr/share/mime-info/fooviewer.mime
/etc/mime.types
/etc/mailcap
/usr/local/lib/netscape/mime.types
I can't even figure out what the heck Mozilla uses for local MIME types... It apparently isn't any of these, in the version of Mozilla I have. I see it makes some nice XML files for user defined types, but those don't work with plugins.
Why can't we just standardize on using
I've had enough abrasive sigs. Kittens are cute and fuzzy.
The author of this article brings up a lot of interesting points, but I think one thing he failed to address was some of the advantages the file extension style of metadata continues to have over the other types discussed. I have been tinkering with OS X for the last few months, and while I have generally been pleased or tolerant of the changes I am experiencing coming from the windows/linux pc world, there is one issue that really strikes me as I read this article. I am a student at Stanford University which has all of its users home directories mounted on a very large AFS network along with countless other schools. This is a very useful feature as I can seamlessly use my home directory on almost every campus machine (be it Mac or *nix, no Windows implementation yet I'm afraid). Naturally, when an AFS implementation was released for OS X, I wanted to give it a whirl. You can imagine my surprise when upon mounting /afs in OS X, the Finder window that automagically opens for newly connected/inserted media almost immediately locked up. I thought it might just be a bad implementation in the AFS client, but after reading a few posts on mailing lists I figured out what was actually going on:
/afs/athena.mit.edu/users/j/d/jdoe.
.app extension (remember OS X apps are actually "bundles"/directories that have a .app extension) but it also figures it might as well look in every singled directory for an included metadata file named "Contents" which every OS X application is supposed to have. So basically, my machine was opening every single server root in /afs, connecting to something like 40-50 AFS servers *worldwide* to see if they were applications or not. Needless to say this can take quite a long time, especially on a slow connection, and could probably have been mostly avoided if it had simply respected the file extension all applications have to use anyway. I guess the morale of this story is, file system and seperate file metadata are all fine and good, but they can be a real pain in the rear for networking file systems if they are the only means of determining file type.
** Background **
For those of you who are not familiar with AFS, it is a large-scale network filesystem which uses the domain names of the various server as sort of their filesystem roots. For example, John Doe's home directory at MIT might be
** Background **
Apparently, when OS X connects to a network file system and opens the Finder window for that file system, it also goes out to check to see if there are any applications it should know about in that directory. Now here's the kicker, apparently the Finder doesn't just stop at checking for the
1.) make sure apps hide file extensions, preferring, instead, icons .tar.bz2 to signify bzip2'd tar files, right? Get ready for 8bim.tif. (for anyone curious, 8bim is the creator code for Photoshop docs on a Mac.)
2.) Hell, UNIX people use extensions like
Really, there's the wonderful, superior data you get on a Mac when dealing with a Photoshop TIFF. "8bim" as the creator code (huh?) and the more sensible "tiff".
Sure, sounds great. *rolls eyes*
Sure, feel free to rip me a new one if I didn't use the proper terminology. I mess with ResEdit maybe once a year. :-P
Stating on Slashdot that I like cheese since 1997.
I purchased a book on JavaScript about two years ago with an interesting bug. The book contained a CD with many examples. It was generally oriented towards Windows, but I assumed that there would be no problem in using the files on Linux and Macintosh systems. I was almost correct.
To my surprise, most of the code did not work. Investigation revealed the all files were referred to as *.html in the code on the CD. In a misguided attempt to DOSify the CD, all files were stored with 8.3 formatted names. Windows happily went looking for the xxxx yyyy z.html, translated the name into xxxxyy~1.htm and loaded the file. Linux and Macintosh computers went vainly looking for the actual name referenced in the code. I had to copy the files to disk and rename them all in order to use any of the examples! I think that this is an excellent illustration of both the baggage inherited from DOS, and the author's point that the name is a poor place for important information.
I agree kind of with this. But Mac OS X fixes this. In the file info there is a place for application. Where you can choose a application which opens only that file or opens all files of that type.
Ok, first, the linux system of actually lookin' in a file to see what file type it is seems pretty un-idiotic to me.
But more importantly, I strongly disagree with your point about ACLs. Different priviledge levels might be useful (as opposed to simple user-or-root), but I don't see a good reason to apply this to a filesystem. As it is, it's very easy to see quickly exactly who has what rights to what area -- with complicated ACLs, everything can get confusing and you might not notice a security problem. Sometimes simple is good.
The private groups notion is far from an "ugly hack" -- in fact, there's no "hack" involved at all: it's just *using* the group and umask functionality in a nice elegant way.
AC's dead wrong and it's just silly. I mean, thinking about file size for a second... if the system doesn't know how long that "ordered set of bytes" is, how does it know when to stop reading? You could have a file end marker, of course, but there's more metadata for you.
It just goes to show that the loudly incompetent are too incompetent to have inklings as to their own incompetence.
I am the one true god. However, as an atheist, I don't believe in myself. I guess I have a self-esteem problem.
Just by telling you their names, you also know something about their types:
John is male
Sarah is female
Matt is male
Duh. A name is supposed to describe the object it represents. Including the type of an object with its name has been around a lot longer than file systems.
it seems as though there are two main types of metadata: OS dependent and user dependent. the OS dependent metadata is information important to the system (permissions, ownership, filesize, etc). everything else (file type, etc) would be user dependent.
i'm wondering if there would be a way to have the OS dependent data remain static (as it usually is), but have the user dependent data be variable. for instance, you could have a 'type' field, but you might also want an 'open', 'print', or 'edit' field to specify perhaps which applications would be responsible for those actions.
for example, i might view images in GQView, but i can't edit them in that program. so, i'd create a new metadata field called 'edit' that would maybe point to the Gimp as the editor for that file. as long as the OS and/or programs i used adhered to this, life would be simple.
since the user dependent metadata would be variable, not all files would need uneccessary metadata fields. but for those files where the end-user might want a broader range of actions associated with the file, many different possibilites could exist.
of course, file-type information would not have to be the only thing stored in metadata. you could have version information, author information, authoring program, etc... but the metadata would only include that which the user would want included.
just an idea...
The point is that you like to see the type as a name next to the file. This is a question of interface, not of metadata. The SAME information for the extension could be shown there.
You could sort by Type instead of "By Type - a hack off the extension".
The point of this was that there is no advantage to storing it in a limited extension as opposed to meta data.
Even more important (that the article went into) is that you can change the extension without changing the file. Think about that, you've changed what the type of the file is without altering the data? That is the point of keeping it as Meta-data, the type should never change without changing the data inside it to another type.
Alex
- John argues that the OS can handle flattening files and creating file extensions when they are written to transports & filesystems that don't support the MacOS metadata properly.
-
John argues that the user should always have control over a file's naming and not the OS, yet acknowledges that renaming-with-extensons will often be required in a networked multi-OS environment.
-
Finally John views the possibility of Apple moving from it's MacOS X HFS+ native filesystem to some other with alarm; I see this as evolution.
Apple no longer lives in it's own comfortable bubble. It's now a peer OS in world increasingly sophisticated and fast-moving. Having grafted MacOS's strengths onto the Next operating system Apple has now entered the rejuvenated unix environment and needs to compete not only on it's own terms but also on those of the other modern operating systems.This relies on the MacOS always having appropriate mappings between filetype/creator codes and those annoying DOS extensions - not something that is always possible. Furthermore in an increasingly networked future it's not always assured that files will pass directly in & out through the OS but rather will likely just as often come & go through alternate transports, all of which would have to all be rewritten to support this. As this enforced-extension functionality is already standard in many applications it seems reasonable to simply codify it there then rewrite everything else, particularly as the creating application will have far more insight into the appropriate extension then the OS could.
Personally I would always prefer any extension-addition be made and clearly communicated when I explicitly create a file and not later when it passes in and out of MacOS-metadata-supporting networks and filesystems. Just as John is appalled at the proposal for hiding these extensions from the user's view I'd be appalled at their being automagically added to my file's names at some later date when they may get moved around or viewed from another OS. At least when I name a file "whiz" and the application insists on creating it as "whiz.bang" I know about it, I don't find out later that my "whiz" is that on some servers and "whiz.bang" on others or it's "whiz" for the other Mac users and "whiz.bang" to the *nix & Wintel folks.
HFS+ is a fine filesystem but it's unique in an increasingly unnecessary way. Other more modern filesystems are being created and if MacOS X is to remain current it needs to keep up and take advantage of these advances. Journaling filesystems are poised to become a standard feature of modern *nix implementations - should Apple lock themselves out of this? Furthermore it's not obvious that new filesystems will necessarily obviate the MacOS-metadata (ReiserFS seems particularly well poised to eventually incorporate much of this) but preparing for all eventualities seems wise.
While it remains important to retain those strengths that have made MacOS such a survivor it's also necessary to not hobble it with dependencies on unnecessary Apple-only limitations. Flexibility is the order of the day and this includes some reasonable level of filesystem versatility. Apple already supports a variety of filesystems now it's come time to allow for the possibility of multiple "native" ones while retaining much of it's vaunted metadata strengths.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
Mac files do take some extra space, but it is the resource fork that causes it, not the meta data. Since the resource fork is implemented as a separate file, a small Mac file uses 2 disk sections, not one. The type/creator meta data is only 8 bytes.
d ata-6.html ("Second, I mention it because...")
The article addresses the common misconception that the resource fork is meta data at some length in http://arstechnica.com/reviews/01q3/metadata/meta
I agree that handling metadata in MacOS should be easier. Just a simple command to view and edit them would solve most problems. But don't confuse that lack of tools with a fundamental problem with the nmeta data concept itself. And as someone else pointed out, there are rpetty good freeware tools available. to fix this.
After using the Mac for 10 years (and the PC alongside... and a lot of Linux as well), and after reading the mentioned article, i must say the Mac way is the best way -- in a closed model. For years, it's been so conveinent: no file extensions, nothing to worry about. Heck, even I add ".txt" to a Photoshop file, it'll still open with Photoshop correctly.
.psd. That's really a Photoshop file!" So, it opens then with Photoshop. Alright sir, 'nuff said.
Add to that Windows.
Now the Mac has to be aware of Windows files. It's a Mac "control panel" called File Exchange. If there's a file without a type/creator metadata (which the Mac depends on, in part), File Exchange says, "Hey, that's a Windows file that ends in
Add to that networking/internet.
Now the Mac not only has to worry about file extensions, but also its forks (data fork / resource fork). So if I send a program over email -- even to another Mac -- the result will be garbled data that won't work. I have to first convert the Mac file to MacBinary -- which squooshes together the forks. On the other side, it can be uncompressed into a two-fork program again and it works perfectly.
Eh, sorta annoying, but I compress things I email anyway because I hate emailing huge files.
Mac OS 9 gives me no problems. Files work right over PC networks, etc. Mac OS X works even better over networks -- in fact, in my work it is much smarter and works more efficiently than Windows NT (or even Linux).
The problem? Now Mac users have to worry about file endings --- in a sense. Applications use the Bundle methodology. Works great!
Files, on the other hand, *sometimes* need extensions.
When don't they?
If the file is opening in a "Classic" application (meaning it is being run through the old mac os 9 codebase... though it's not really "emulated"). Because those "old" files HAVE type/creator codes the Mac understands.
When DO they?
If it's purely a Mac OS X file, for the most part. Now in 10.1, the file endings can be hidden. But that doesn't solve the real problem: the Mac is battling PC/Unix files from the net AND its original OS 9-and-lower files that now have to carry redundent metadata.
Apple really needs to solve this. I know a lot of the OS X programmers, and they're extremely committed and bright, so I'm sure the problem will be fixed. Most importantly: make the Mac work great over the 'net (which is does really so far), AND make the experience very easy. I HATE file extensions. I love the old type/creator method. But I'm sure it could be done even better to satisfy all.
The next comment I write will be ready soon, but subscribers can beat the rush and see it early!
A few articles at The Register have talked about how MS will be "building SQL Server into the OS - effectively making the file system a relational database." This will greatly improve efficiency, and concentrate them into one database format instead of a mixture. And its even probably legal.
I think a lot of the metadata haters just don't know what metadata is doing for them. Every time you hear someone say "Mac OS is more elegant", they really mean that it doesn't keep popping up dialog boxes telling you off or warning you you're about to break something. Much of the time this is because that information is being stored and so applications just generally appear to know more about what's going on, so they don't have to ask the user.
Not having a satisfactory method for modifying metadata is hardly an argument against having metadata; it's just an argument for having a satisfactory method of modifying metadata. There are countless utilities on the Mac for doing this. All Mac OS X needs is to show a field for file type along with the field for filename and permissions and such in the file Inspector.
The argument the article makes is that we shouldn't just throw away all the metadata that's already attached to files just because it's inconvenient to store it on legacy filesystems.
This isn't a problem with metadata, just a problem with MacOS' file typing.
BeOS handled all this very well. Double click to open with the default app. Right click to see a list of every program on your hard drive that opens that kind of file or files like it. (IE, a text editor would show up as an option for an HTML file.) Choose another option and open a dialog to set a file-specific preference.
I must have said "BeOS did it better" about six times today. I feel like an Amiga user.
"Files" are an abstraction.
"Files" are used for both data transfer and data persistence.
The brilliance of Unix, was, that everything is a file. Which allows amoung other things for a kind of closure ( i.e. cat fred | awk | sed...).
It is a very useful abstraction.
The abstraction has limitations.
When transfering data - you have to describe what the data is (metadata). The description must be in terms of a common frame between the transferring parties. or the data must be "self describing" at the file level or the protocol level.
When storing or persisting data - you want it to hang around reliably and efficiently. There are layers of implementation and interface. The requirements of these interfaces are not the same as for data transfer.
I think some of the reasons for these difficulties is taking the file abstraction too seriously, and not considering the difference between storage and transfer.
i.e. I agree with the conclusion reached by the article - other OS implementations are bleeding into OS X in the name of interoperability. They dont have to, you just have to know that there is some sort of transformation between the files that are stored and the files that are transmitted.
No the AC is not wrong on the issue of file size.
There are two sorts of information at stake: one is data which is an adjunct to that contained in the file; the other is information that is a function of the data in a file. Size is a function of the file data, which is an ordered set of numbers. Sure, this number has to be stored somewhere, so that the files can be meaningfully read - but then so do the bytes of the files themselves! Storing the size is simply an implementation concern - the size is an intrinsic property of the data.
The more information you can extract from the file contents itself, the better in my opinion. Metadata - as the article pointed out - can easily be mangled or lost. In this regard, I'm a big fan of the default Unix scheme of /etc/magic, though I do strongly believe it could be improved. We can't throw out all our old file formats, but we can certainly agree on a standard form of file preamble, which say contained a mime type or other globally recognized unique type identifier, to be applied to new formats developed. Some mechanism for users to be able to extend the /etc/magic system would be nice, too.
tell application Finder
set creator type of file foo to "8BIM"
set file type of file foo to "EPSF"
end tell
run that in smile and your problems are solved... or, you can just use snitch.
2 1337 4 u!
I agree, the BFS is one of the most impressive things I ever layed my eyes on.
Commander Taco is not circumcised. That's why he smells so bad...
LoL!!!! Somebody mod this UP!!!!
That is an interesting, but probably not good idea. Be tried basically that idea with their first file system, and it was pathetically slow. BFS has database-like elements, e.g. the journal and the indexed metadata in key = value format. Dominic Giampaolo and his team at Be learned the hard way that putting an actual database in the filesystem is not good. Practical File System Design with the Be File System (ISBN 1-55860-497-9) is a good read about how filesystems work, and only requires a basic knowledge of C to understand. He talks about BFS, ext2, XFS, NTFS, and HFS (focus on BFS of course) and how they address several design issues. I recomend checking it out.
Similarly, the windows system, with file extension associations that are essentially a total mystery to the average user is also tremendously confusing. You can install some lame-ass scanner software and have it decide that it owns all the image file types you used to have associated with photoshop. Now, how do you get back to normal?
The point that I'm making is that doing almost anything "automagically" has the potential of being a source of confusion. UI designers need to think a little bit more about empowering the user rather than just concealing things from them. Obscurity != ease of use.
(I strongly suspect that hiding file extensions by default was a really bad idea.)
You failed to mention that it is your picture up above.
> I agree that handling metadata in MacOS should be easier. Just a simple command to view and
> edit them would solve most problems. But don't confuse that lack of tools with a fundamental
> problem with the nmeta data concept itself.
The problem is that we already have a much simpler and more elegant solution for the most commonly used metadata, type/creator. I do not think it is at all possible to make it eaiser to access and change type/creator from a GUI, than it is to access and change the file extension. So if there is no advantage to type/creator metadata, there would be no reason to use it at all. I spent the better part of my post above showing why type/creator metadata causes problems when files are exchanged, and how it is just as easy to use the context menu or Send To submenu in a Windows system to launch different files of the same type in different applications. Therefore, I see no reason to have type/creator metadata in the first place, since simple typing by extension with a context menu available on right-click is at least as effective, yet provides more flexibility in terms of the context menu commands or Send To menu apps available to launch the file, and easier and faster access to manipulating the file's actual type.
I think the problem is a narrow-mindedness on the part of *some* Mac users, who have not cared to even learn the Windows way of doing things and so think the Mac's metadata is some huge advantage when in fact the Windows way is easier and more flexible if you give it a chance. The MacOS simply lacks an equivalent context menu and Send To submenu--the context menu it has isn't as powerful and flexible, and so cannot do the job, and so Mac users see anything that relies on a context menu to be suspect if it could be done without. Of course, Apple would have to adopt a standard 2-button mouse before it could implement a system that relied on the centext menu for opening files in alternative ways, and Apple is so unfortunately wedded to the 80s notion that more than one button would be too confusing for new users. Funny how new Windows users seem to get the hang of it...
Point is, I am a Mac fan, but use Windows too and can accurately judge the features of each. And I can say that Windows' simple file extensions are eaiser to use and manipulate, while its adaptive right-click menu gives you almost all the advantages of type/creator metadata with even more flexibility and none of the drawbacks. I'm glad the newer Linux GUI environments are mimicking this aspect of Windows, rather than the metadata of MacOS. As I said, I cannot think of a way to make the metadata as accessible through the GUI as a file extension is.
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
The most common scheme for metadata support under Linux is to treat directories and directory trees as units of information; Linux end-user applications unfortunately don't take enough advantage of this. Another common scheme now is to use XML. Yet another approach is to use a relational database for metadata.
What UNIX/Linux is missing is file change notifications and efficient support for lots of small files. ReiserFS looks to change that.
Windows NT and its successors have, in fact, database-like functionality and multiple forks in their files. I very much hope Linux will not be following either MacOS or Windows down this path. UNIX was in part created as a rebellion against that kind of creeping featurism.
Why does the file name have to be there?
Why are we still using file systems?
Computers are quite capable of managing huge organized trees of data. Why are we still fighting with bitstreams like this?
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
-
If the data is XML-formatted, you could
look for something like a DTD or schema reference.
-
In OLE-land, a DocFile is structured as a container of typed files, recursively. The type of the top-level container can be considered the type of the file. DocFiles themselves start (or end) with a distinctive signature.
You can still use Mac OS X in "the old Mac style" in terms of not paying attention to extensions, but it's sad to see the backwardness of the rest of the world finally taking its toll. Perhaps it is time for a standards group to come up with some minimal metadata interchange ideas and apply them to data transfer protocols. It's pretty obvious that MIME would be one of the building blocks.And, on the broader subject of metadata, I think that at least two of the native Lisp Machine file systems (one of which was written by RMS) allowed for user-defined metadata in the form of a property-list, so you could store any property on a file as long as the data that was PRINTed could be READ back in.
Hardware failure I think. :(
Unless a string of data is floating about in a vacuum, with nothing else to be read, there is nothing to distinguish the bytes in that string of data from bytes in OTHER strings of data. If you add an EOF marker so the system knows where to stop, that's additional information. If you add DCB information with the requisite BDWs and RDWs like on an MVS system, then no EOFs are necessary because the systems counts until it has as many bytes in memory as it was told were there to be had and stops.
SO, file size is most definitely metadata. There's no way of knowing what is in a set of data unless you have additional information which is not the data itself.
Even is this was not true(say, in the data-in-vacuum example), the fact is that META data is "data about data". As others have said, just because the information is intrinsic to the set doesn't mean it is the same as the explicit data itself. I can tell by browsing the hex of an AFPDS file that it's an AFPDS file, so I could write that information somewhere else close by, and it would be metadata, even though it was derived. The simple fact that it is an AFPDS file does nothing within the context of an AFPDS file. By the time it's being processed AS an AFPDS file, the fact that it's an AFPDS file is pretty irrelevant and changes processing not a bit. If it was really a saved character from Everquest that happened to also function as a valid AFPDS file, nothing would change about the result.
As long as you think a file preamble/header/footer/whatever is NOT metadata because it's "in the file", then you're never going to understand what metadata really is. Do you see?
I admit to being an asshole. But that doesn't mean one don't deserve to be pilloried when one tries to pretend one knows one's shit better than the guy writing the article - and fails.
And btw, if you don't know my (rather obscure)acronyms, just ignore them. Their particular meaning is not important to the argument.
I am the one true god. However, as an atheist, I don't believe in myself. I guess I have a self-esteem problem.
BeOS does this so well, that I use it as my MP3 juke box. The ability to search using a GUI, in milliseconds for songs from a particular artist, or title, running on an OS that boots up in seconds means that there will always be a copy of BeOS in my house for this purpose to make use of old second hand Pentiums that people think are too slow for their latest and greatest copies of Windows.
The reason why I'm being such a jerk about this is that John is being so cool and really quite nice to all you self-impressed punks. Since he's not willing to give you the what-for, someone should write in service of the scales of justice. I know I'm not the only person on /. tired of people imagining themselves such experts that they can talk about "fallacies in fundamentals" and lay down the law. ArsTechnica is generally scrupulously accurate and it's the height of pomposity to be like that when you don't actually know what you're talking about. It's damned disrespectful of soemone who's trying to share his knowledge with you FOR FREE!.
So be quiet.
I am the one true god. However, as an atheist, I don't believe in myself. I guess I have a self-esteem problem.
While AmigaOS used .info files to keep track of things like applications, I did like the way IFF was used as _the_ file format. Sounds, images, they were all was stored in IFF files that kept track of what exactly the file held. Sort of like a bundle.
Then there was Data Types. The theory was that if an App knew about data types, it didn't need to know how to write a particular format as long as Data Types did know. I liked this idea. If a new format came around, I didn't need to update all my apps (as long as they knew how to use Data Types).
Xix.
"Everything is adjustable, provided you have the right tools"
Yes, index.html is an HTML formatted file - yet it's also a TEXT file - and it may contain Java/PHP/etc Scripts embedded in it. Do I want to limit a file to only one "Type" when it can be many, depending upon how I choose to use it at a given moment? Of course not!
It's true the older MacOS file type methodology worked well when the Mac was used as a much more limited system. The fact that MacOS X includes Apache is an example of how much more versatile the Mac is today. In order to be more versatile, you have to reduce some things to the LCD. To do otherwise limits the usage of the system and that's exactly why the Mac has remained the cherished possession of so few. To expand market share, Apple needs to expand the uses of the Mac - that means more flexability, and less stringent ties to those technologies (however useful in old-school aspects) that limit that flexability.
I AM, therefore I THINK!
In the current shipping version of MacOS (read X) you can "Show Info" on a file (same thing as in "Get Info in OS 9) and there is a pull down menu that gives the option application. Its very easily noticed. There you can reset not only the meta data for that file, but also, the default for all files of that type. You no longer need to use file typer. Anyhow in OS 9 this was a non-issue. If you wanted to open something with a different application, all you had to do was drag the file onto the icon for the app you want to launch it. You could even do multiples.
"I hate downloading things on a Mac because of this. Some idjit will have a file set to open in an application I don't have"
This is deceitful. If you download a normal everyday file off the internet, odds are not going to get the meta information of that file, even if it was orginally on the Mac. Almost every single application for downloading on the Mac uses the System level settings for mapping extensions to type/creator, which will ALWAYS be an app you have. The only times you will get meta info with the file is when you 1. download a stuffit archive and 2. use hotline. I personally can't remember the last time I downloaded a file as a stuff it archive, unless it was an installer, which in that case it was irrelevent since it was self contained. Now if you are heavily using Hotline for exchanging files, then odds are you are a pirate and deserve what you get.
Burn Hollywood Burn
One thing that bugs me: when a program (e.g. Nautilus) builds a thumbnail for an image file, the thumbnail isn't attached to the file, it is stashed somewhere (e.g. in a hidden directory called ".thumbnails" or something like that). This is a hack.
It's worse when you have multiple programs that want thumbnails; there isn't a standard yet and you get multiple thumbnails.
What I really want is some metadata attached to the image file, and the thumbnail in there. Then when you copy or move the file, the thumbnail goes along. And of course we need a standard so all the programs that want thumbnails will all do it the same way.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I'm biased though, as I'm working on a global metadata repository.
Its not metadata which takes up that space, its hidden resource files. The mac metadata really only is 8 more bytes then other OSes. It is a different issue.
But if there is one thing I intensely dislike about MacOS, it's the metadata. I know I'm practically alone in the Mac camp, but I hate metadata. I have always thought it was just a space-hogging pain in my ass. Now, the space issue is no longer a big concern since we have such big, cheap drives that a little filesystem metadata isn't such a burden on capacity. But back in the days of floppies I was pissed that I could fit so few files on a floppy when my friend with DOS could fit noticeably more. I was especially annoyed that even when I formatted a disk as a PC floppy, the Mac would still waste my space by creating and hiding from me files and folders on the disk to constiture the resource forks. I wanted every kilobyte, which counts when you're cramming a lot of small files onto a lot of small disks.
What the author of the article is missing is that what he calls "File Type" is actually representing two (or more) things.
1. The type of data represented by the file. This can be used to help an application know how to load the data, or more importantly, to help the USER know what is contained in that file.
2. The application which the user prefers to view/edit this file with. This depends on the user, on the machine, on what apps are installed, etc.
IMHO, he is too tied to the one-type-one-app view of the world. For example, take C++ programming. Most people use a directory for a project. In that directory, there are numerous files many of which have the same names. You end up with Foo.cpp, Foo.h, Foo.obj, Foo.exe, etc.
In a world where all those files are called "Foo", you end up with a very confusing directory listing. That directory listing to be usable has to display the type attributes anyway in order to enable to user to know what to point and click on.
Another alternative would be to disallow files with the same names in the same directories, so what happens to those files? One option would be to rename the files "Foo Source" and "Foo Header" etc. but this is cumbersome and stupid. Another option would be to offload the helper files into other directories, but then you end up encoding type information in directory names instead of file extensions, which I'm sure we'd all agree is even worse.
Another example of how this is messed up would be transferring files from another computer. If I transfer Foo.cpp from one Mac to another, the Creator information comes with the file. What if the file was created on emacs and I use vi? Or What if I use MS Visual Studio? What if I uninstall MSVS and install the Borland IDE? Do all my files break? Now I can't launch anything?
What application to launch really doesn't have much to do with the creator field. And file extensions have other uses besides indicating a launch target.
"The difference between theory and practice is small in theory and large in practice..."
The main issues regarding file attributes are "how do you find it", and "what do you do with it when you've found it". UNIX users are used to thinking of these as being tied strongly to file names, but that's not fundamental. Consider Microsoft's Fast Find and Active Directory, for example. Or the way the MacOS handled applications; it didn't matter where they were, because there was a database (the "desktop") that automatically tracked them.
Much of the complexity associated with UNIX programs involves finding their various parts. This usually involves some combination of path variables, configuration files, command line options, shell scripts, and fragile directory tree structures. Something better is needed.
A separate issue is whether files should be flat streams of bytes or should have structure. The Mac had both; the "data fork" of a file was a byte stream, and the "resource fork" was a tree of records, rather like the Windows registry. This was a good idea, although it suffered from the fact that the machinery for updating the resource fork was prone to corrupting it, which discouraged its use for dynamic data storage. (Or, as Apple put it, "the Resource Manager is not a database.")
Many of Apple's better ideas suffered from what Mac developers called the Mess Inside. One major effect of this was that things that required keeping complex data structures consistent didn't work too well. Application bugs could corrupt the desktop or resource forks, and the system-level machinery which processed those data structures didn't check them. ("It's more fun to be pirates" - Steve Jobs.) So data tended to turn to mush, which gave resource forks a bad name. Today, most programs store all the important stuff in flat files.
UNIX was not the first OS, nor was it designed by committee. In fact, it was designed by a small research group in reaction to the excesses of systems like MULTICS (hence the name). Today, Windows NT follows in the MULTICS footsteps, with excessive APIs, redundant functionality, and a special-purpose API for any conceivable application. The lessons of UNIX are as relevant today as they were 30 years ago.
Compared to Win2K, Linux's technical advantages are pretty minor.
The advantage of UNIX (and to a more limited degree, Linux) is absence of features. Microsoft cannot catch up with that because they are moving in the wrong direction.
Microsoft has moved on, it's important for the UNIX community to do so as well. ACLs (implemented on NT) are FAR more flexible than users/groups.
How naive can you be? Do you think people at Bell Labs didn't consider ACL-like mechanisms? Don't you think they would have added them by now to Research Version 10 or Plan 9 if they thought this was the right thing to do? The creators of UNIX have never been constrained by committees or backwards compatibility: they have always done what they thought was right, and they changed things when they believed they had done something wrong. ACLs, so far, haven't cut it for them. You may disagree with their technical judgement, but don't attribute that disagreement to some nebulous notion of being outdated or old-fashioned.
HOWEVER, the system of making things conveniently obvious for the CLI results in engineering decisions that give the OS less flexibilities. GUIs can provide TREMENDOUS ammounts of information BECAUSE the user decides when to get that information.
As the Windows NT file properties dialog shows, GUIs don't help one bit with this problem. Yes, you can present lots of information in a GUI, but users can't process it any better than they could with any other method of displaying it. In practice, if you actually allow users to maintain their own ACLs, you end up with a complete mess of permissions on your hands.
Let's get back to the overall point. Of course, there is a need in the world for systems like MULTICS and Windows NT. There has always been, and there always will be. That's not because they are any better designed or any more modern, but because such systems satisfy the preferences and tastes of the masses of programmers. But that doesn't make such systems well-designed. As far as I'm concerned, systems like UNIX and Plan 9 are the systems for the thinking programmer, and MULTICS and Windows NT are the "lowest common denominator", catering to the masses who don't know any better. Which is also why I observe with a lot of concern the attempts to turn Linux into Windows and add all that Windows junk to Linux. As far as I'm concerned, that's not progress.
As others have pointed out, BeOS did this right by making this part of the interface instead of like a Mac where the type/creator info is hidden from the user and not editable without downloading additional software.
Just to nitpick-- you can change the file/creator types using Applescript, which comes installed on every Mac. That doesn't mean, of course, that your average end-user is going to do this.
The way it's supposed to work, you can drag your icon onto the application you want to open it with, and then save it from within that app. Presto, the icon changes, and you never have to see a 4-letter code. My problem with it is that there's no easy way to de-associate a file from all apps.
- MFN
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
Remember what the author of the article said: Just because you are offended by a particular behavior that an OS does, doesn't meant that it's the fault of the metadata itself.
Having a file type stored in the filesystem itself, rather than in the filename, only means that the interface to present and change the information has to adapt.
For instance, on the Mac, if I want to open a document with a different application than the one it's bound do, I right click on the file and choose a different app under my "FinderPop" popup menu. It's a tiny piece of shareware that let's me do this. Granted, I'd like it in the OS itself, but it's seamless for me.
Changing the type, I have to admit, really is a pain in the ass on the Macintosh. I hate having to pull up a special program and type in some special codes to do this. What a pain.
But many things can be gotten around, assuming that the file system will support it.
Soon we'll have to take this to e-mail :)
One could define metadata as any data associated with some other data, but isn't that a bit broad? It really does encompass everything from word count to plot description. Surely a more practical definition is data which is not just associated with, but additional to the original data in question.
That's a debatable point. In the broadest sense, then yes, size is metadata, but then so is the byte-frequency histogram of the data, or the number of odd-length words found in the data, and so on. The most broad definition of metadata is too broad to be useful. Perhaps there is a comprimise position, but I can't see anything wrong in working with that outlined above.
With the issue of size: sure, it has to be stored somewhere (or equivalently, with an EOF marker.) So do the bytes of the file. So do the error-correction bits stored on the hard disk (for example.) My point is that the singly-forked unadorned file - in the abstract - is a finite ordered set of bounded numbers (typically bytes). How that set is represented physically is an implementation concern, and will have to include an encoding method for the bytes themselves, probably some error correction at the lowest level, and of course the size, too. Finite sets by their very nature are delimitted somehow - if they weren't they wouldn't be finite!
The file-type of a file might be stored seperately (as metadata); it might be derivable consistently from the file contents (as metadata). It's not an intrinsic property of the ordered set of bytes the file represents - it's entirely up to interpretation within the computing context. This is unlike size. Size doesn't care what the content is. Size is a necessary and constant property of any finite set of data.
To take the example of the AFPDS data, the fact that you can tell it is an AFPDS file relies on information external to the simplest file abstraction. It requires an external context, that of the AFPDS file format, for the file type to be derived. There's nothing intrinsic to the ordered set of numbers that makes it so; it could well be weather-data to some other software.
I also need to address this statement:
The size of the data is part of the data itself - well, more precisely - once you have described a set of data, you have also described its size. To be repetitive, storing the size, or an EOF marker, or somesuch is simply part of the representation of that set. Once could represent a file by a single huge integer, and then store that integer on disk, for example, impractical though it be. (Of course, the actual representation of the integer on disk would probably in the interests of space efficiency be delimited in some way.)PS: I had never before encountered the acronym AFPDS. I looked it up in an acronym index, but it wasn't very enlightening :).
PPS: One can extend the abstract file notion to include streams, which are ordered possibly infinite sets of bytes (or whatever). Take for example, /dev/zero under Unix. In such a context file size doesn't make a lot of sense, but this is only tangentially related to the argument.
That's right. You need third-party software to change the file type on a Mac, and even then it's not easy.
It's as easy as dragging the file icon to an app that can read it, then choosing "Save." Don't have an application that can read the file? PCs aren't immune to that problem either.
If the file type is incorrect, that's when you need to mess with the codes. And you can use Applescript to do it, no need for third-party tools.
While Windows maintains a correlation between filenames and descriptions (.doc = Microsoft Word Document, for example) there is no such listing in Mac OS. True power users are just supposed to know that MSWD is a Word document.
So is that ".doc" file a Word 6 document? Word 3.0? Word 97? They all fight over the same extension, but the file formats are different. This example is far from being a rare or unusual case.
- MFN
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
The definition of metadata isn't "useful information about other data" or "data about other data we've decided to store" or whatever. It's just "data about other data". Yeah, frequency histograms are usually pretty useless as metadata, but they are still metadata. I just wouldn't have the system track it.
Another definition for metadata that is insufficiently conclusive is "data outside the fiel describing data inside." What you decide to call a "file" is really a question of convention. They are not necessarily contiguous on disks, for example, and are generally the logical representation the system offers to an application. If the system knows which bytes to offer, it's already read the file size somehow. In mainframe environments they don't even talk about "files" most of the time, generally preferring different ways of representing datasets. So, as you were mentioning the different ways of "representing" sets, you were showing that you actually agree with me but you keep stumbling over the PC baggage of the "file" term. Perhaps it was a bad choice to include it in the conceptual part of the article, since it tends to lock people into a way of thinking.
As for the AFPDS thing - I really don't remember what the hell I was trying to show there. Doing too much crack, I guess. Maybe I'll figure it out later. In the meantime, AFPDS is a flavor of mainframe printstream. I spend a good portion of my day slogging through data and metadata at the byte level, troubleshooting printstream transforms. Mainframe print environments have impossibly convoluted metadata structures.
I am the one true god. However, as an atheist, I don't believe in myself. I guess I have a self-esteem problem.
What does C:\ONGRTLNS.W95 mean?
On MacOS 9 you usually get a nice window which lets you pick an app to open the file with.
Files that come from the Internet or a PC automatically get the proper type and creator (most of the time).
It's also quite easy to change the type/creator for a power user. You should not act like all Mac-users are dumb.
The Drowned and the Saved - Primo Levi
Weve been struggling with filesystems for a long time now. But IMHO filesystems for themselves are some sort of "hack". In the end its all about data, so why not faciliate applications which are "experts" in handling data: databases! This of course sounds like the wording of an ORACLE representative: "everything is a database". But hey, at least with files theyre right. Why we still dont put our data in databases is still a mystery to me ...
No creation dates!
only atime, mtime, and ctime.
And we all know, if it wasn't designed 30 years ago, UNIX won't adopt it.
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Which brings me to all the other operating systems of choice, which may partly have file system support for metadata, but certainly not application or tool support. For that to arrive, file system support for metadata must be pervasive --- otherwise, applications would have to decide
I'd suggest the way that MacOS does it with its applications -- simply package everything into a directory. That directory could contain a file with a fixed name, describing what type file this is (Apple uses "Info.plist" in XML), and any number of data streams -- one, perhaps, for the binary file data itself, a couple for resources, etc. etc. The resulting dictionary (I'll call it a "package") can be manipulated by legacy tools, and there could be library support for the format to make it easy for new tools to make full use of it.
The only problem I see with this is that this directory would have to be encoded for transmission over the net; but that's the problem that John wrote about, and could be solved by simply making a tar file of the directory. That even has the added advantage that there's tool support for tar files on just about any platform, which is more than can be said about MacBinary.
Any comments?
In other words DumbName.jpg and DumbName.txt should not be allowed in the same folder. Then hide all the file extensions and the users would be none the wiser. Yes I would. Especially in the terminal, where I want things to behave like they should bloody behave. In other words DumbName.jpg and DumbName.txt should not be allowed in the same folder. Then hide all the file extensions and the users would be none the wiser. Yes I would, didn't you hear me the first time? Those are two different files with two different names, and I don't care what you hide! In other words DumbName.jpg and DumbName.txt should not be allowed in the same folder. Then hide all the file extensions and the users would be none the wiser. Fine, be that way, but I'm never going to use a nutty OS that acts like that. And don't ask me to use an OS that has a universal handler for files that end in .jpg either. If it doesn't have an application specified then give me a list to choose from, don't go assigning things to it for me.
-- thinkyhead software and media
The current problem is that filesystems don't make it easy to store properties of a file. The HFS made a brave attempt by dividing files into content and properties (using data and resource forks), but it still didn't objectify the filesystem. For example, creating children of a particular file necessitated converting the file into a folder and then wondering what the hell you were going to do with the folder properties - were they going to be placed within the folder or within the parent folder.
A solution would be an object-oriented filesystem, that allows every file to have children without nasty conversions, and implements a simple store for properties (a Berkeley DB file would seem a natural solution).
> I agree kind of with this. But Mac OS X fixes this. In the file info there is a place for application. Where you can choose a application which opens only that file or opens all files of that type.
Did you actually tried it ? I mean, half of the time it is greyed, half of the remaining time opening the 'Choose application' dialog freezes the Finder. When it works, it generally forget to save the option.
Face the truth:
1/ Mac OS X Finder is a piece of shit.
2/ The ars technica writer is overly verbose
3/ He is a mac weenie, and love everything apple did.
4/ File type were wrong since the start. Is HTML a text file or a HTML file ?
5/ File type as implemented by the original mac are even worse (An editor that can open TEXT file cannot open an HTML file)
6/ Don't get me started on file creator.
7/ Any idea that "an utility exists that can alleviate the problem" is stupid. It works out of the box, or it doesn't.
8/ File extensions are a bad idea. But those are necessary. NeXT, for instance, implemented those correctly.
9/ Resource fork are even worse than file types
10/ Standard are good.
11/ Converting from names to extensions when 'externally storing files' is not such a good idea. It is the kind of ideas that make parts of Mac OS X unworkable on UFS.
12/ Making comparison between file type and file size is mindless advocacy.
13/ A gzipped text file is not a GZIPped file. It is a GZIPed TEXT file.
14/ Interoperability imposes the use of file extensions. So file extensions should be used.
15/ Mac OS type/creator were painfull in 1986 (when I started developing for it). It is much more painfull today where my personal mac is networked with several FreeBSD boxes and a windows one. And when my Mac can boot 4 operating systems.
16/ file(1) is good. The OS should make use of something similar (ie: each app-maker should register its extensions and provide a machine-readable description of how its file type can be recovered from content). This database should be maintained up to date, and used by the OS when file type is unknown.
Cheers,
--fred
When I first read through this article I thought.. yeah that makes sense.. but sharing files over a LAN is much more important for my business than over the Internet.
.psd (source files) and which are .gif (final output).
At least once a week we run into a problem where a PC programmer has to go to a Mac Artist to find out what kind of file was just sent.... this is useless communication.
In addition it's very useful to look at a folder full of files and at a glance know which are
Sometimes I want vim, sometimes I want gnotepad, sometimes I want something else. I never want Word, and I don't want some stupid meta data setter telling me I do. No, thank you, DickBreath.
Friends don't help friends install M$ junk.
Like I said, I never want Word. It would really upset me to Work on a project with some dickbreath who used word, if his modifications would make name.c open up that way from seeing the brilliant created with metadata.
Friends don't help friends install M$ junk.
Distinguishing filetype based on extension is what many of us are used to. So a .h file is a header and a .c is code. How can one tell them apart if there's no extension? Well... modified ls would do the job. Even changning from one type to the other wouldn't be a problem: 'chtype file1 HTML' If you get used to the idea that extensions don't belong to the name you could easily 'vi index.html' to create a file 'index' (just name) with associated filetype HTML in some other database.
/etc/magic (or /usr/share/magic), and close. Very expensive, but just 'SELECT type FROM utonto WHERE name=p0rn' is quite faster right? Installing new kernels would just require recording it's inode on the kernel-type table. LILO just parses it and present the list of available ones. Libraries? Just the same and it actually isn't conceptually different from moving the bits from one place to the other in the filesystem.
/dev/*? Oh well, just a matter of adding entries to the db. Publishing a page on apache simply means adding it to the apache-table (and this is what we conceptually do when we copy the file in /var/www/html) Folders and files are just an implementation of database storing that was familiar to people used to filing cabinets. It's just A way to
/lib)
'ls *.c' becomes 'ls -T x-csrc'
Actually it all boils down to ditching the idea of a FS as nodes/leafs. Way cool would be that a make install on an app would mean simply changing it's type from plain object code to systemwide executable without even moving it from it's physical location on the hd. It's a tremendous change... I can't even think of all the consequences. One though would be fenomenal:
how do I distinguish filetypes if they don't have extensions? I open the file, read the magic ID in it's header, compare to
Creating
do it and perhaps there are more efficient ones. Rumors say M$ is going that way, BeOS did it long ago and for UNIX the switch wouldn't be traumatic (if you had code to map user files to a fictious ~/ or systemwide-lib table to
If it ain't broke don't fix it: true. The filing cabinet is a metaphorical interpretation to data storage that produced the current filesystem architecture; it works but we could grow out of it and move to a object-relational dB system that could provide enhancements to data sharing (NFS anyone?) and access control.
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
Sorry to crash your party, but the MacOS does exactly what you are talking about... it allows you to choose which application you open a specific file with, in addition to setting the default for that file type. Very handy when you get a file from a web site without a file extension, but you KNOW it's a .zip archive...
"Politicians find new names for institutions which under old names have become odious to the people."
Linux does have file change notifications, it's just not integrated with the mainline kernel yet. IIRC, it's SGI's Irix implementation which they opened for Linux.
One of the reasons I advocate Macs for my print centers is that it does track both the file type and the creator code. When your primary job is handling incoming files for output, it's essential information to know if that EPS was created by Illustrator, Freehand, QuarkXPress or a WindowsNT Postscript print driver. It tells the output technician what program to open and what problems to check for.
But don't treat a "creator" as an "opens by default" tag - that's not what it's there for. For my part, I wish the creator code had a paper trail. If I knew that this EPS file was created by QuarkXPress, pulled into Freehand, exported to illustrator and then rasterized in Photoshop, I'd know a heck of a lot more about why it's not printing the way the customer expects.
I can see that in other environments this information may be superfluous, and the default opening application might rather be set to something else. The best point the author of this article made was that how a file opens should be easily configurable by the user - either open in the native application, or open in something else. Let us decide. But the metadata that supports that action is immutable, and should be saved with other immutable data, not with the stuff that can change irrespective of the data.
--Any sufficiently reliable magic is indistinguishable from technology.
I'm talking about a modern UNIX, meeting the resent specifications (I believe UNIX 98 is the most recent).
The ORIGINAL UNIX was designed well for its time. I would suggest that there is little in common (code wise) between the original UNIX and modern UNIXes. The BSDs and Linux share NO code with the original. While the commericial UNIXes may share some code, overall the have been rewritten.
Now, each vendor makes their own UNIX. The "Linux" distributers make their own system, though the kernel and the C-library appear to be standardized.
The point that I am getting at, a modern UNIX is a well engineered machine. However, when you write portable code, you write either to the specification for all UNIXes (the designed by committee standard that hasn't been updated in 3 years, and most of the standard is MUCH older), or you write to a particular UNIX. Yes you can write a fall-back to the standard and optimize for your platform, but you really haven't helped then, have you? Your platform is optimized, the rest just run.
Take a current issue in the BSD community. The BSD rc system is beautifully simple, and less of a mess to manage than a SVR4 system. However, it does have some problems in that there is no easy way to bring down/up services, etc. We wrote our own service script (inspired by Redhat's, but custom to us) that we edit the configuration for as we add services. This gave us some control of the system.
NetBSD wrote a new rc system that uses shared scripts and small configuration files for each daemon. It seems to be an intelligent system, without the mess I have seen in Linux systems.
FreeBSD appears interested, and will likely adopt it.
For reasons that AREN'T clear if they are technical or political, OpenBSD will not. This means that people writing to the BSDs can choose to support two systems (the NetBSD/FreeBSD AND OpenBSD), or target one platform (either NetBSD/FreeBSD OR OpenBSD).
Now in this case, the rc system, it is less of a concern. Targetting both is trivial. However, as most people use FreeBSD or NetBSD, those of us in the OpenBSD community are part of a smaller niche.
However, we see the potential for a problem. Targetting the BSDs requires targetting BSD 4.4. Any extensions made by the BSDs may or not be ported to the rest. Playing nicely with Darwin/MacOSX is another problem, but Apple seems to be willing to follow FreeBSD's lead on the BSD side, focusing their creative/decision process on the Aqua/Quartz side.
To get the BSDs to move foward, you need a committee that shares improvements (unlikely for political reasons) and gets them standardized when everyone moves foward.
IDEALLY, you can target your platform of choice, but the features you want will be in the other platforms within 1-2 years. That way, you can even have a fallback for lagging systems. However, there should be a process by which useful extensions become part of the base, so the base is slowly evolving.
I understand your preference for a less-is-more approach, which I think makes sense for the system/kernel. That design philosophy encourages better systems. However, when there is a way to do something, there should be an attempt to develop the best way, then everyone should use it instead of reinventing the wheel.
The core UNIX system has two standards, POSIX and X11. Both of those systems were designed separately, and you can target them and it will work everywhere.
If you want a GUI app, targetting X11 is a pain. Targetting Motif is slightly more pleasant. Targetting Qt is easier. However, you can't target ANYTHING but raw X11 until you know that the standard requires something.
That is what I'm getting at. Motif was adopted as the UNIX standard long ago, but it's non-free status has kept it out of Free systems.
Java promised to be that universal platform that we could all target. In an ideal world, there would be no more native code for applications, all new applications would target the JVM or something similar. Java offered the idea that MFC did for Windows programmers, a real environment to build applications in. Unfortunately politics and other limitations got in the way, and we still don't have a universal platform. Targetting all UNIXes is okay with an LCD approach, targetting all UNIXes and WinNT requires a different approach. But nothing out there presents a good way to move the common base foward so I can build an app that is optimized for everything, or at least will be when everyone catches up.
Alex
And that's easier is it?
Go back to your Jobs-worshipping you prick.
ACLs (Access Control Lists) are a very nifty feature in a network environment. They provide a much better control for the end user.
But nobody ever uses them. Why? Because there is no real standard (just a draft), every Unix (Solaris, HPUX, IRIX, AIX) and WinNT on top of it uses its own scheme, and they're all incompatible.
So part of the problem is standardization. The Mac file TYPE has the same problem. While Apple theoretically is the single authority on this, there are many non-registered file type fields in use and it keeps getting worse.
Guess what happens if two applications use the same file or creator type, but with different content? - Ay problema!
Idempotent operation: Like MS software, wether you run it once or often, that doesn't make it any better.
Current shipping version of Windows (ME) does not allow that. You have to right click on the file and get the properties dialog, because....the extensions are hidden. Second the current version of Windows has a VERY archane dialog for changing default apps for a given extension, compared to the elegance of OS X, is next to useless.
"You are of course aware that type/creator is not in the resource fork for Mac files, and so if you download a graphic created with Mac Photoshop, it will usually want to open in Photoshop if you have it installed?"
Just not true. Netscape, IE, all every FTP app I can think of all reset the type and creator on download, if it is there at all. They use the builtin database in MacOS for determining the type/creator, which will ALWAYS be set to an app you have. As I said the ONLY times I know this will happen is when you 1. Download a stuff-it archive and 2. Download from a Hotline server that is Mac based. As I also said, I can't recall the last time I downloaded a file as a stuffit archive and Hotline is for pirates...
Burn Hollywood Burn
A filesystem is a service. It (should) provide storage and retrieval of any string of bits that will fit. The only essential (key) metadata is the filename/location (address) information. Dates and permissions/ownership are metadata that the filesystem provides for itself, and related file-management software.
File type metadata is redundant. For proof, I offer the example of steganography software. The essential part of steganography is the ability to look at data which appears to be unusable and yet somehow extract data which conforms to our expectation. My point is that file type metadata can be computed from the data itself, and therefore any stored designation is arbitrary and unneccesary.
You might think "why not talk about magic numbers?" Let's do: steganography can be computationally intensive. If you don't need to obscure the data's purpose, why not embed a label in the data itself? Oh! We do! Most (well designed) file format specifications include such a designation in the first few bytes of their internal structure.
Theoretically, a filesystem can do its job without knowing anything about the file contents. Oh! Some filesystems do! Utilities which manipulate the data served up by the filesystem cannot read and write files without prior knowledge of the file's contents. Which (application or filesystem) should be authoritative on file types? That's right: applications!
What happens when you ask the filesystem to choose which application to handle any given file? Then the filesystem needs prior knowledge of *all* file types for every file. It needs some kind of file type metadata on every file type. Windows handles this with the registry each time an application is installed: it tells the filesystem what kind of files it uses and how to recognise them (by yucky filename extensions). But, wait! That's Windows Explorer I'm talking about: a utility/application NOT the FAT32 or NTFS filesystem. Unix has a similar function called "magic". It is also an application/utility and not part of the filesystem. Even NeXT bundles (meta-files?) in MacOS X (and GnuStep) place the onus for file handling on the applications.
The file browser is an application, and it has needs which are a subset of filesystem needs, a subset of each application, and a set of its own peculiar features' dependancies. The Mac Finder, Windows Explorer, and every X-Windows filesystem browser (browser for short) has strategies to deal with each of these sets of needs. Let the browser handle the file typing! What is the problem?
Oh, that "creator" metadata that assumes you have several applications that handle a given file type, but you prefer to open a file with the application that created it, creates a knowledge gap between the application and the browser. Doesn't that break the assumption that a file type is a standard and that software should not assume one application is better than another?
Oh, I forgot: Mac users have been promised they won't have to make any unnecessary choices (like which JPEG application to use for each file). This is an optional feature of a "Mac flavored" filesystem browser and should be implemented within the browser itself. How should (say in MacOS X) the filesystem browser get the creator metadata from the application? How about using RCS style metadata? Isn't creator information really historical data? Who should handle logging a file's history? Traditionally, that would be the application. Maybe the API should provide transparent historical metadata maintainance and hooks for the filesystem browser to access this history?
First I have a system, and it works, but leaves me with too many choices. Next I want the system to have intuition so I can avoid making some choices. Now my once clear system is as complex and muddy as my own thinking as I digress and eventually undermine my working system's design.
You see, eventually the historical metadata can become a neural network and anticipate data handling in more sophisticated ways without even the programmer having to make decisions about data handling...
--- Nothing clever here: move along now...
>4/ File type were wrong since the start. Is HTML
>a text file or a HTML file ?
It's a text file, and that's what's so great about the MacOS. An example: I write some html-file using bbedit. It's got the correct html-ending, if I double-click it in the finder, it gets opened in bbedit, but I can still also edit it with any other Mac-program that knows text-files, even if they don't know about html, because they can *see* that it's a text-file. without me having to change the file extension. having type/creator-codes doesn't mean that the editor can't look at the file extension to figure out what kind of, say, text-file it is.
Nautilus and Konqueror do it too, BTW.
As for changing file names of a big batch of files, A Better Finder Rename does this admirably. Not sure if it can also do batch changes of file type -- I'd have to check.
I love the fact that some of my JPGs open in PictureViewer, some of them open in GraphicConverter, and some of them open in AOL.
double-clicking opens in WinAMP, right-clicking and choosing "edit" opens in SoundForge.
That is indeed a nice feature. But it has nothing to do with the fact that the file type metadata is appended to the file name. Apple could choose to implement this type of functionality with file types/creator codes in their present location. (And I wish they would!)
file extensions... make the type of file crystal-clear
Umm, no. I use my Windows box more hours per day than my Mac, and I doubt I will ever memorize what all those three-letter extension signify. Sure, I know the common ones -- DOC, XLS, EXE -- but for 95% of them I have no idea.
In contrast, icons on the Mac are usually so artfully done there's no question what app a document belongs to. Even various flavors of documents for a particular app (for example, the distinctive QuickTime icons for Mov, JPG, MPEG, MP3, etc.). And yes, Apple has human interface guidelines which tell developers how to make application icons quite distinct from document icons. Those guidelines are quite effective.
That that is is that that that that is not is not.
tell application "Finder"
if document files in selection as list is {} then
display dialog "No document files are selected." buttons {"OK"} default button "OK" with icon caution
else
set these_items to (document files in selection) as list
repeat with this_item in these_items
set the creator type of (every file of selection) to "TAR"
set the file type of (every file of selection) to "TARF"
end repeat
end if
end tell
> Current shipping version of Windows (ME) does not allow that. You have to right click on the
> file and get the properties dialog, because....the extensions are hidden.
Bah. No one who knows anything about Windows uses ME. It's just Win98SE, but slower and bloated with more useless features. But even if you *are* using it, just click on the "View" pull-down on any open window, select "Folder Options," click on "View" tab, and un-check the box that says "Hide file extensions for known file types." Then the file extensions will always, always, appear for all files.
Before you complain that that's complicated, you only have to do it once--and anyone with even the most basic skills knows that he needs to customze his preferences when setting up a box, whether Windows, Mac, or *nix. And you also should be aware that Apple has plans to do the same little preference about showing/hiding file extensions in the next OS X release. It's a way to make the extensions invisible to really dumb people who wouldn't know what to do with them and shouldn't be allowed to accidentally change them when they change a file's name, but still allow users with a modicum of experience (enough to un-check a box, which isn't much) to do their magic. And BTW, I did point out in my original comment that showing all file extensions is no longer the Windows default and must be changed by the user.
Therefore, that "arcane" dialog box for changing extensions in WinME is unnecessary once you un-check a prefeence box.
> Just not true. Netscape, IE, all every FTP app I can think of all reset the type and creator
> on download
If that's true, it's insane. Do you know what a CRC or CSV or SFV is? It's a small algorithmically-derived digest of a file, or of an entire set of files, which can be downloaded and automatically check the files to make sure none are corrupted. These are very commonly used to ensure file integrity, whenever there is a file or series of files of some importance which one wants to ensure are completely original and intact. Since type/creator is not in the resource fork, but in the file itself, altering them would alter the file in a very small and usually insignificant way, however the CRC/CSV/SFV would be rendered absolutely useless, since a change of even 1 bit would show up in the digest and therefore the file would be reported as corrupted. That is just insane, if true. My downloading software should IN NO WAY modify my files, without my explicit knowledge and permission. It renders file integrity checking utterly useless.
The last version of Netscape I have ever used, on a Mac or otherwise, is 3.04Gold, so I would not know. I do recall that Netscape had a list of "helper applications" for what app should open what file--but that was only used if you selected within Netscape to "Open" the file upon download, not when just "saving" a file. I now use IE on Windows and Mozilla on Linux, though when Mozilla for Windows gets a bit better and faster, I plan to switch to that too. If what you said is true, though, it is absolutely stupid for the reason I mentioned above. You can't have file verifitcation if your OS midifies the file in any way whatsoever. File verification is especially important when downloading software; the software companies, particularly ones who make security software, often offer CRCs to their customers so that the customer can be confident that he has not received a trojaned or otherwise interfered-with software package.
Second, you may not download much in StuffIt archives (who does)? But I download an awful lot in Zip and RAR archives. Doing that on a Mac would not affect type/creator of the files within the archive. In fact, you will find that Zip is the most commonly used method for transferring multiple files at once.
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
First, you say we don't need no stinkin metadata, then you say we need it with more power and flexibility.
I think we can all agree that application binding is a cool thing, and saves us a lot of work as an automatic shortcut to opening documents.
The problem here is, and NOBODY has gotten this right so far as far as I'm concerned, is having a decent way for power users to edit and manipulate metadata, and configure the OS's treatment of it.
Yes, the high and mighty programmers have access to it. The hackers have access to it. The grannies don't want or need access to it as long as application binding functions in a basic, and intelligent way. The power users have access to it, the same way the hackers do - but it's often a pain in the ass, using tools that weren't really designed to do anything other than mess around. Nothing useful can be done with these tools ON ANY OS, in terms of allowing a power user to quickly and easily manipulate the metadata to set up a custom behavior that suits his or her purposes.
And that's really the whole problem.
That, and of course the fact that filename extensions really have got to go.
You'd think that the OS vendors would think about this, and provide the users with some nice tools. And I'll agree with you, Microsoft's solution is kind of nice. Where the CM for a Batch File in explorer will give you the choice to RUN the batch file, or Edit it. I think power users need that kind of flexibility for html as well, OPEN the file in a browser, or OPEN the file in an editor.
I'm often frustrated with graphics files - sometimes I want to run a quick image viewer to display an image file - sometimes I want to tear it up in Photoshop. Launching Photoshop is a 60-second ordeal on some people's machines, and it's a necessary ordeal if you want to do serious editing.
You see the problem here? Granny needs the file to open in her browser on a double-click. The power-user or content creator needs TWO choices on the execution of an icon. Edit or View. And in the case of executible content, Execute. This needs a user paradigm - probably a lot easier to use than a CM. And it must be MUCH quicker than the stupid "open this unregistered file in one of these " deal, which is annoying and slow on every OS I've seen it.
when I think about how annoying this problem is, and how NOBODY has ever offered a real, workable solution for this. I see - an opportunity. . .
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Bzzt..Wrong. It's stored in the inode tree, not the file. The moment you copy a MacOS file to a flat file system, it looses this information permenantly. Now if you copy to a PC zip disk it APPEARS to keep it, but in reality, it stores the information on invisible files.
"But I download an awful lot in Zip and RAR archives. Doing that on a Mac would not affect type/creator of the files within the archive"
Bzzt...Wrong. Both zip and rar do NOT keep MacOS style meta data post compression. Not only that but Mac users almost exclusivly use Stuff it for compression. I know I do, because...drum roll please....it KEEPS the meta data post compression.
Burn Hollywood Burn
what are you fucking talking about? malicious executable README displayed as what, a *text* file?
no, the file will have an *application* icon. how many text files are distributed as applications?
and even if the asshole who would try something like this uses a custom icon (and giving up a big clue, why distribute a macbinary text file?), he would be foiled by the power macos users, who do not always double-click documents.
many of us drag files on top of the running app icon, because we need to deal with files using different applications.
look, if it is so fucking easy to dupe mac users, why isn't there a vbs-outlook-microshit-virus insanity on macos? outside of office, viruses on macos are nearly extinct.
to be clear, such files without special macintosh formatting to preserve file metadata/resources will open harmlessly as gibberish in a text editor... and if a trojan does sneak by a user, it will almost certainly be vulnerable to a quick force-quit, if not being shut down by virex or another utility.
Then explain to me how this happened:
Just recently, when I ran across some old Mac floppies, I read them and transferred the graphics files to my PC using MacOS 8.1 running on Basilisk II, then running HFV Explorer from within Windows I transferred all the graphics files from the Mac HFV file to my PC's regular FAT32 file system, then later transferred them to another HFV containing System 7. When I booted System 7 through Basilisk II the files still sometimes opened in JPEGview and sometimes in Graphic Converter. That sort of information should not have survived going from HFS to FAT32 back to HFS if what you say is the entire story. And HFV Explorer can't be responsible since if it were it would have chosen to give all the files of the same type the same type/creator codes.
And the reason I was doing all these transfers, BTW, is that I'm creating a 200MB (or greater, as necessary) HFV file for use with 68k Mac emulators filled with Mac software and files commonly found on a Mac in c. 1994-1995, for historical puposes. Many of those files, and much of that old software, is now nearly impossible to find, so I am archiving as much of it as I can to be released in 2005 as a sort of abandonware homage to the Macs that were in use when the Internet made it mainstream. I find most of it in dusty old subdirectories of academic institution FTPs, which I fear will start cleaning house sooner or later and permanently losing a lot of those archaic files.
At any rate, I have seen type/creator codes, particularly on graphics files, survive on FAT32 systems and on Zip archives I made ages ago.
You may continue to argue all you want, but this has been my experience, the experience of someone who has both FAT32 filesystems, HFS filesystems, and others all on the same computer. What you are saying may or may not be correct, but it is still clearly not the whole picture since it contradicts my direct and extensive experience at transferring files across filesystems.
Chasing Amy
(We all chase Amy...)
"The more corrupt the state, the more numerous the laws"-Tacitus
If I remember correctly, the reiserfs system is designed to be extensible via plugin modules, and could possibly add this type of metadata and even file specific database stuff (like artist and preferred playback volume for an mp3) that could then be searchable via file utilities.
am I correct?
there's no replacement for displacement
And there you have it. File typing and filesystem metadata for the UNIX world. Elegant, no? Just because existing filesystem metadata implementations are absurdly complex doesn't mean they have to be. Note also the use of MIME types, to further simplify and standardize the file types.
Debian already does it sorta like this, only it uses file(1) magic to determine the MIME type, rather than using filesystem metadata. (Debian users: It's in the mime-support package.) Still, it provides view, edit, and other such commands, for performing various operations on files, regardless of their file type. It also can understand when (not) to run X applications to view/edit/whatever the file.
Yet another fine example of the reasons why Debian is the One True Distribution.
The only way the typical /.er can pick up a chick is with a forklift. -- AC
So would data about Metadata be... "Gitadata"?
I know, but I just had to.
Kurdt
I'm not anti-social. Just pro-technology.
Although I generally agree with your wiewpoint, I have to point out that I have seen README type executable files on a small but significant amount of shareware programs.
The text file is usually distributed in an archive with the executable program, so that it can be hard to notice the custom icon.
So in conclusion, the best way to operate on a Mac OS ( X) would be the standard power-user setup, list view with file details (Metadata) shown, and launch non execuatable documents by dragging them onto the applications. This allows maximum flexibility and control. Many Mac users use program launchers, floating palettes and toolbars containing their favorite apps for easy access. I usually just have aliases of my media viewing apps in a folder that can pop-up when I need it, then get out of site when I don't.
BTW, for non Mac users, an alias is like a soft link to an inode. Thus it behaves like a soft link except that isn't broken when the original changes locations (like a hard link).
Although I generally agree with your wiewpoint, I have to point out that I have seen README type executable files on a small but significant amount of shareware programs.
The text file is usually distributed in an archive with the executable program, so that it can be hard to notice the custom icon.
So in conclusion, the best way to operate on Mac OS (not X) would be the standard power-user setup, list view with file details (Metadata) shown, and launch non execuatable documents by dragging them onto the applications. This allows maximum flexibility and control. Many Mac users use program launchers, floating palettes and toolbars containing their favorite apps for easy access. I usually just have aliases of my media viewing apps in a folder that can pop-up when I need it, then get out of site when I don't.
BTW, for non Mac users, an alias is like a soft link to an inode. Thus it behaves like a soft link except that isn't broken when the original changes locations (like a hard link).