[Big Mac]

Originally Posted by John Gruber

A few months ago, I heard suggestions that Apple had tentative plans to release a developer beta of Mac OS X 10.7 at WWDC this June. That is no longer the case. Mac OS X 10.7 development continues, but with a reduced team and an unknown schedule. It’s my educated guess that there will be no 10.7 news at WWDC this year, and probably none until WWDC 2011.

Apple’s company-wide focus has since been focused intensely on one thing: iPhone OS 4.1 The number one priority at Apple is to grow mobile market share faster than Android. Anything that is not directly competitive with Android is on the back burner.

So the trollish but somewhat serious question is, is Mac OS X still important to Apple? Is the Mac platform still important to Apple? Or is Apple signaling that the Mac is on the way out?

[mduell]

Consumer electronics, particularly the shiny ones, are way more profitable and give you more control over how they're used. Unfortunately they're also not very sticky, so when you stumble you disappear; pervasive DRM helps a lot here to raise switching costs.

[lpkmckenna]

The Mac is not "on the way out." Seriously, without a Mac how will anyone make iPhone apps? Or any other creative task?

[turtle777]

I think we've gotten spoiled with past OS X release cycles.

Right now, SL is less than a year old, and plenty capable.
As much as it would be nice to know more about the next release, there is really no immediate need.

-t

[Atheist]

What are you looking for in 10.7? SL is very stable and robust. Besides something like support for the ZFS file system, what other functionality do you think we need?

[Wiskedjak]

Originally Posted by turtle777 

I think we've gotten spoiled with past OS X release cycles.

Right now, SL is less than a year old, and plenty capable.
As much as it would be nice to know more about the next release, there is really no immediate need.

-t

I think Apple has dug themselves a bit of a hole by equating point releases (10.1, 10.2, 10.2, etc.) with full releases.

[P]

ZFS isn't coming, but we do need a new filesystem (for licensing reasons, though you'd think Larry could cut Steve a deal on that now). That might very well be why development takes time: Remember that MS completely failed to deliver their new filesystem (WinFS) that was meant for Blackcomb, and that even the HFS+ release was delayed back in 8.1. Making new filesystems is hard. If Apple takes a year to just make a new filesystem on top of SL and then actively start developing 10.7 and ship the filesystem with it, I'm totally fine with that. That filesystem development doesn't necessarily require a big team.

[imitchellg5]

Originally Posted by turtle777 

I think we've gotten spoiled with past OS X release cycles.

Right now, SL is less than a year old, and plenty capable.
As much as it would be nice to know more about the next release, there is really no immediate need.

-t

Exactly right. I feel as if SL is the most refined version of OS X. I really don't have any complaints at all. Plus, as more and more apps go 64-bit, the experience will get even better IMHO.

[besson3c]

Originally Posted by P 

ZFS isn't coming, but we do need a new filesystem (for licensing reasons, though you'd think Larry could cut Steve a deal on that now). That might very well be why development takes time: Remember that MS completely failed to deliver their new filesystem (WinFS) that was meant for Blackcomb, and that even the HFS+ release was delayed back in 8.1. Making new filesystems is hard. If Apple takes a year to just make a new filesystem on top of SL and then actively start developing 10.7 and ship the filesystem with it, I'm totally fine with that. That filesystem development doesn't necessarily require a big team.

A better file system is really the only major feature I can fathom Apple adding to OS X at this point, it is a fully cooked OS. I mean, there are always new GUI tricks, little utilities and widgets and various other doo dads you could add to it, but nothing that could really take the OS to a whole other level comes to mind except maybe resolution independence?

A new file system *would* take OS X to a new level:

- the possibility of building systems with dynamically expandable redundant storage, perhaps little Flash based or Solid State drives you can pop in and out as needed. Not only would this allow you to add additional storage, but it would protect you against a drive failure. Maybe this sort of thing wouldn't be terribly necessary with Solid State drives coming down in price (whenever that happens), but I think that a new file system such as ZFS could be an important part of an important shift in how storage is used moving away from mechanical parts and adding intelligent software failsafes and notifications. I can't really put my finger on any particular prediction, but it is clear that relying on a single mechanical drive is something that will eventually be phased out.

- the ability to create and destroy new filesystems (partitions) on the fly right within the OS, which would allow further sandboxing, additional file sharing functionality, and all sorts of consolidated storage appliance type solutions. Quotas can be set on filesystems to set disk space limits.

- I use ZFS and I can take a backup snapshot of 30+ gigs in literally a couple of seconds. It doesn't really matter how large the data set is, snapshots are super quick. This would definitely take Time Machine to a whole other level. The snapshots also take up very little disk space and do not consume inodes

- ZFS RAIDs are self healing and data is copy on write. A new filesystem such as ZFS, BTRFS, or whatever Apple makes (if they model it after one of the former) will put an end to Diskwarrior and fsck.

- Moving away from a dual forked filesystem will improve write performance significantly

- ZFS supports on-the-fly compression which saves disk space, and also actually improves performance in most cases. Deduplication features also save space

- ZFS supports file system replication to reconstruct the same data and all snapshots on another computer. This makes it easy to create mirrors and test environments without having to bring down the machine or wait for a zillion years for a clone operation or file based sync like we do now


I've been using ZFS on my production servers for a while now, it has literally changed the way I do business. For instance, I can easily provide a 6 month backup window or beyond quite inexpensively without getting into various tradeoffs (e.g. longer fsck checks, greater probability of file system corruption, etc.) as this is extended.

It is a big deal!

[Simon]

I'm not worried about Mac OS X. SL is in excellent shape and I too can only agree that what's missing now is 'merely' a FS upgrade.

I do wonder how seriously Apple takes the Mac though. First they gave up on having a wide range of models. Then they gave up on a large part of the desktop segment and now they're seriously lagging in the pro department. This entire consumer focus makes it more difficult to deal with Apple in professional environments. Sure we love their consumer gadgets, but we can't earn money with an iPod. I need a bad ass Mac to do that. It appears as if Apple has become a bit lazy. It's obviously easier to make profit off a million iPods compared to selling a hundred thousand Macs.

Also, I have the feeling this isn't over yet. First there was the iPad and the whole iTunes thing taking up resources. Then when we thought the focus was slowly returning to the Mac the iPhone popped up. There go those engineering man hours. Three years later the next big bang and again it appears most hardware engineering resources went into this little gizmo while the Mac had to sit it out. So is this how it's going to be? Every three years a major new device, new OS, new hoopla and every time the Mac is put on hold for extended periods of time while Apple and Steve the magician try to surprise the whole world?

[Big Mac]

I agree in large part with your analysis, Simon. The Mac is getting the short shrift. I think it could make sense to spin out a wholly owned subsidiary to develop the platform, since Apple's main concern seems to be the digital lifestyle now.

[Simon]

In other words we're asking for the resurrection of Apple Computer, Inc.

[Big Mac]

I suppose so, yeah.

[Simon]

Well just for fun, let's play devil's advocate then.

What does Apple need the Mac for nowadays? iOS development does not necessarily require Mac hardware. iTunes runs on Windows.

[Big Mac]

The Mac brings in revenue, and an increasing amount at that in recent years. There wouldn't be much in the retail stores if not for Macs. Clearly it's in Apple's financial interests to continue investing in the platform in a serious way, but it may not have the corporate focus to be able to develop the Mac to its fullest along with the iPlatforms.

[Simon]

It's a dangerous argument, but I agree. I just hope that's not at all there is. If the iPlatforms at some point generate a substantial fraction of Apple's revenue they could be inclined to focus. For instance by dropping the Mac.

[Big Mac]

I think Apple would only drop the Mac outright if it were a financial loser for the company. Clearly it's not. But it's also clear to me that the platform isn't getting the attention it deserves.

One other point in response to one of your previous posts: Slimming down the range of Mac models was very necessary to get the Mac division back on planet earth. All those models were terrifically confusing to the market and were definitely taking a lot of unnecessary resources to maintain. The big problem is, with such a tight product matrix that modern Apple has, and with Apple's desire for fat margins, the iMac has encroached on pro-level pricing territory, and the pro desktop line has gotten increasingly expensive so that those in the market for a regular desktop have no choice but to go Hackintoshing. It's something I'm strongly considering in delving into in the near future. I never thought I'd buy PCs or hack my own Mac clone, but Apple leaves me little choice. That's pretty pathetic.

[Simon]

I think nobody will doubt trimming the line down was necessary at the time. The issue I have is that even now with Apple in much better shape and the Mac selling well, they refuse to cover key areas.

[Big Mac]

I can agree with that sentiment, but then again perhaps the company thinks the Mac line would be less profitable/successful with more choice - that the amount of choice currently delivered is all Apple can provide without sacrificing profitability. They tried low-end G4s and low-end G5s, but they proved unsuccessful despite lower pricing because of the deep hardware cuts Apple made in delivering those models.

[P]

What is needed from a new filesystem is, IMO, a way to combine flash storage with disk storage. There should only be one unit visible to the user, but the flash drive should be used to accelerate the experience as far as possible.

Beyond that, HFS has too much overhead, but I think that it's pretty clear that a new FS would have to do something about that in any case.

I don't really have a problem with SL+running updates being the OS for a long time, but there are more things than the FS that needs a big update. Apple is behind on security, with ASLR STILL not being implemented for all relevant libs and sandboxing only being used sparingly. In general I think that AppKit needs to keep evolving in a way that requires major non-fully-compatible changes to the API, and change like that are why we have version numbers in the first place.

[Wiskedjak]

I'd be happy if the OS played more nicely with network storage. It's a complete PITA having to deal with mounted network drives. If the network connection disappears for a few moments, OSX freaks out and starts asking me to disconnect the drive until the network reappears. If I do disconnect, then I have to reconnect when I need the drive again. And, never mind *finding* network folders without already having an alias.

[OreoCookie]

I think it's only a shorter term problem: most technologies that come to bloom on the iPhone OS have had time to mature on OS X. That's the reason the iPhone OS is ahead of its competition.

However, not only OS X suffers, if you have a look at Aperture, it looks as if they have implemented localized edits. Then, they ran out of time and asked people from the iApps team to help them out (Faces and Places have a sub-standard UI that looks as if it has been taken directly from iPhoto, ugh). I've read rumors that this may have really happened.

For the next version of OS X, I hope for the following improvements:
(1) Broad use of sandboxing and other security improvements.
(2) Resolution-independent UI.
(3) Next-gen filesystem. I was very disappointed when Apple pulled the plug on its plans to use ZFS. (I've accumulated 6 external harddrives already )
(4) We've all heard rumors of the next-gen OS X user interface (Marble, wasn't it?), perhaps we'll see that. (Not that I think this is really, really necessary to overhaul the UI.)

Even though, I don't think Steve will pull the plug on OS X (what is he supposed to use if he wants to work?!?), I wish they would hire more people so that they can continue their efforts on the desktop OS front.

[voodoo]

I'd like to see a good, solid Finder. Not this mishmash we are currently suffering with - the current Finder is more or less irrelevant in day to day use of the Mac. Instead one uses all sorts of shortcuts to avoid having to deal with the Finder itself.

So, FTFF. Properly. Make a proper file browser and make the Finder itself properly spatial.

[slugslugslug]

I sometimes wonder how much I would appreciate it if they went back to a spatial metaphor for the Finder. The lack of it doesn’t bother me that much, but it’s been so long since I’ve used OS 9 that I barely remember it. On the other hand, I use Windows XP at work, and at least that version of Windows Explorer makes the Finder seem downright brilliant. Ironically, the biggest thing for me is that there are so many things that I can do quickly from the keyboard in the Finder but not Explorer.

[slugslugslug]

Oh yeah, and I’m glad someone got around to mentioning resolution independence. I mean, damn, that was supposed to be in Tiger, and they seemingly just stopped talking about it. But with the big range of DPI in built-in Mac screens, not to mention all the available 3rd-party monitors, I think this should have been a big priority years ago. I want x-point type or y-inch shapes at 100% to be the same size as print on every screen, and I’m not even a designer. Absolute measures are supposed to mean something, and they don’t on OS X.

[Simon]

This just in:

John Gruber: Apple's Focus on iPhone OS 4 Diverting Resources From Mac OS X 10.7

A few months ago, I heard suggestions that Apple had tentative plans to release a developer beta of Mac OS X 10.7 at WWDC this June. That is no longer the case. Mac OS X 10.7 development continues, but with a reduced team and an unknown schedule. It’s my educated guess that there will be no 10.7 news at WWDC this year, and probably none until WWDC 2011.

Apple’s company-wide focus has since been focused intensely on one thing: iPhone OS 4.1 The number one priority at Apple is to grow mobile market share faster than Android. Anything that is not directly competitive with Android is on the back burner.

[Brass]

Please fix iChat in 10.7! It used to be a great video chat platform, but not anymore. The video and audio quality is great, but it's reliability in connecting through some networks is attrocious. Skype is reliable and works every time. Unfortunately, its audio/video quality is poor.

[dedalus]

Originally Posted by slugslugslug 

Oh yeah, and I’m glad someone got around to mentioning resolution independence.

Ditto.

[Big Mac]

Originally Posted by voodoo 

I'd like to see a good, solid Finder. Not this mishmash we are currently suffering with - the current Finder is more or less irrelevant in day to day use of the Mac. Instead one uses all sorts of shortcuts to avoid having to deal with the Finder itself.

So, FTFF. Properly. Make a proper file browser and make the Finder itself properly spatial.

I don't think we'll ever see that happen. If there had been a collective outcry early on for a clean separation between the spatial and browser modes, it could have happened. Now it seems like that particular aspect of the Finder is set in stone. They wouldn't have to make two different Finders, by the way - all that would be necessary would be a preference pane item that allowed for the switching between the two different modes: Finder (browser mode) and Finder (spatial mode). The OS X team just never got that the two modes shouldn't be mixed with each other. The compromise they came up with early on was the toolbar-hiding option to produce a more spatial experience, which wasn't a good compromise at all. If they had provided a preference choice between the two modes, most people would probably stay with browser mode as default, but those who prefer spatiality could turn that on instead or switch back and forth. Too bad it never happened.

Originally Posted by Simon 

This just in:

John Gruber: Apple's Focus on iPhone OS 4 Diverting Resources From Mac OS X 10.7

FWIW, that's the post that I quoted in the original post of this thread.

[Simon]

Originally Posted by Big Mac 

FWIW, that's the post that I quoted in the original post of this thread.

You're absolutely right. Must have missed that.

[Big Mac]

Regarding a new filesystem, do modern filesystems support Mac style aliases? I'm also curious about how moving away from a dual-forked filesystem improves performance.

[Simon]

Im curious, does the old "Mac-type" alias offer anything we really need compared to a symlink?

[Big Mac]

Mac style aliases are more robust than sym-links, which break easily if moved AFAIK. I think there are some unique features of HFS that make them work, and I'd imagine that a design goal for a new filesystem would include such support.

[Art Vandelay]

If you rename or move the target of a symlink, the symlink is broken. Not so with an alias unless you move it to a new volume.

[P]

That is because of pecularity in HFS - there is a file ID that is irrelevant of the filename and path. Aliases use that to locate a file, as do Mac apps when they have a file open. That isn't the way it's usually done on other filesystems, but it CAN certainly be done like that on most (by pointing to the inode number). Unfortunately I'm pretty certain that Apple won't bother - it's pretty well known that everyone who came to OS X development from Openstep or a UNIX hate HFS, and they are likely to throw out everything of it.

I'd also like to see an example of how dual fork support degrades performance - especially as many filesystems support them and rarely use them. NTFS is one such.

[CharlesS]

Originally Posted by P 

That is because of pecularity in HFS - there is a file ID that is irrelevant of the filename and path. Aliases use that to locate a file, as do Mac apps when they have a file open. That isn't the way it's usually done on other filesystems, but it CAN certainly be done like that on most (by pointing to the inode number).

Close. The ID that aliases use is actually a catalog node ID. This is different from a file ID (like an inode number) since it's associated with a node in the catalog file, rather than a file itself. This may seem like a pedantic nitpick until you consider that a file can have more than one hard link, so you can have multiple catalog nodes pointing to the same actual data. An alias would point to one of those hard links, not to the data itself, and if you resolved the path of the alias, you'd get the path to the hard link. If that hard link were deleted, the alias would be broken, despite the fact that the actual file would still exist due to the other hard link to it.

Using the inode number for alias functionality wouldn't work, because there is no way to resolve an inode number to a path — and when you think about it, there couldn't be, because it wouldn't make sense. If there are two hard links to an inode, and you resolve the inode to a path, which path would you get? There would be two of them. Another problem with inodes is that they can be reused after a file is deleted, causing an alias to the defunct file to point to some other, completely wrong file. CNIDs, by contrast, will never be reused, even after the file is deleted, unless the file system completely runs out of CNIDs (and in Mac OS 8.1 and earlier, it didn't reuse them at all — you had to reformat the drive to create any new files).

Unfortunately I'm pretty certain that Apple won't bother - it's pretty well known that everyone who came to OS X development from Openstep or a UNIX hate HFS, and they are likely to throw out everything of it.

Actually, given that they just overhauled the NSURL class in Snow Leopard to finally bring alias-like functionality to Cocoa without forcing developers to go through Carbon for it (even inventing a brand-new, more robust kind of alias called "bookmarks" to do it), I doubt it. Also, back when Apple's alpha read-write ZFS drivers were on macosforge, they seemed to support alias functionality. It seems that Apple is committed to this ability, and I would be rather surprised if any new file system they adopted didn't support it in some shape or form.

I'd also like to see an example of how dual fork support degrades performance - especially as many filesystems support them and rarely use them. NTFS is one such.

The way resource forks in HFS work is that every file record in one of the catalog file's leaf nodes that corresponds to a file contains two extents records, one of which describes where the data fork is located and the other of which describes the location of the resource fork. I fail to see how removing one of these would make things any faster. There are definitely things that could be done differently from HFS+ that would make a difference speedwise, but I don't think the dual forks are one of them.

[Simon]

Any chance Darwin could be updated in such a way to improve symlinks so they also make use of CNIDs? I'm trying to understand if aliases and symlinks couldn't eventually be merged into one common concept.

[Simon]

This just in

Steve Jobs on iPhone development taking resources away from Mac development: 'No' | 9 to 5 Mac

[P]

Excellent post, Charles.

Originally Posted by CharlesS 

Close. The ID that aliases use is actually a catalog node ID. This is different from a file ID (like an inode number) since it's associated with a node in the catalog file, rather than a file itself. This may seem like a pedantic nitpick until you consider that a file can have more than one hard link, so you can have multiple catalog nodes pointing to the same actual data. An alias would point to one of those hard links, not to the data itself, and if you resolved the path of the alias, you'd get the path to the hard link. If that hard link were deleted, the alias would be broken, despite the fact that the actual file would still exist due to the other hard link to it.

OK, you're right (I didn't consider the implication of hard links), but that is a real corner case. How many users know to hard link their files? There isn't even a way to make them the Finder. How many files in the default OS X installation are hard linked? I know that Time Machine uses hard links, but for regular alias usage, hard links are irrelevant.

Originally Posted by CharlesS 

Using the inode number for alias functionality wouldn't work, because there is no way to resolve an inode number to a path — and when you think about it, there couldn't be, because it wouldn't make sense. If there are two hard links to an inode, and you resolve the inode to a path, which path would you get? There would be two of them.

The first one. If it's a document that the alias points to, the position of that document isn't really relevant - it should just be opened. Directories should not be hardlinked (I think that hardlinking directories still requires root access, no?), which also excludes OS X apps. If you have an alias to a UNIX executable with two hard links, then yes, things might get hairy, but now we're talking really crazy things.

Originally Posted by CharlesS 

Another problem with inodes is that they can be reused after a file is deleted, causing an alias to the defunct file to point to some other, completely wrong file. CNIDs, by contrast, will never be reused, even after the file is deleted, unless the file system completely runs out of CNIDs (and in Mac OS 8.1 and earlier, it didn't reuse them at all — you had to reformat the drive to create any new files).

So write the filesystem driver for our new fabulous filesystem to not reuse inode numbers unless it has to.

Originally Posted by CharlesS 

Actually, given that they just overhauled the NSURL class in Snow Leopard to finally bring alias-like functionality to Cocoa without forcing developers to go through Carbon for it (even inventing a brand-new, more robust kind of alias called "bookmarks" to do it), I doubt it. Also, back when Apple's alpha read-write ZFS drivers were on macosforge, they seemed to support alias functionality. It seems that Apple is committed to this ability, and I would be rather surprised if any new file system they adopted didn't support it in some shape or form.

Perhaps. I just keep seeing these rants around the web about how HFS+ sucks and that it was silly for Apple to use it over UFS in OS X. HFS+ has it's flaws, no debate there, but there are good reasons for some of those features, and UFS is no picnic when the file directory starts being flaky (lost+found? ). All of these debates about "the Mac way" and "the Openstep way" seem to end with the Mac way losing because there aren't any old Mac heads left at Apple. If they can kill creator codes on a whim, I certainly think that they can kill aliases.

[P]

Originally Posted by Simon 

Any chance Darwin could be updated in such a way to improve symlinks so they also make use of CNIDs? I'm trying to understand if aliases and symlinks couldn't eventually be merged into one common concept.

I think that it would be best to avoid that, for compability's sake. Let aliases work like an evolution of symlinks (do they even work in the terminal environment now?) and leave symlinks as they are to avoid breaking POSIX compability.

[Big Mac]

Steve Jobs Sends a Few Words of Encouragement to Mac Fan

[Simon]

Originally Posted by Big Mac 

Steve Jobs Sends a Few Words of Encouragement to Mac Fan

In another thread, didn't I just recently link to something you had already pointed out?

Guess we're even now.
http://forums.macnn.com/90/mac-os-x/...e/#post3956537

[Big Mac]

Sorry, hahaha. It was new to me at least.

[CharlesS]

Originally Posted by P 

OK, you're right (I didn't consider the implication of hard links), but that is a real corner case. How many users know to hard link their files? There isn't even a way to make them the Finder. How many files in the default OS X installation are hard linked? I know that Time Machine uses hard links, but for regular alias usage, hard links are irrelevant.

There's quite a lot of stuff in places like /usr/bin that's hard linked, out of the box. And of course, as you mentioned, there's Time Machine. Besides that, you never know whether some user may have some hard links set up for some particular purpose, whether some third-party app will create hard links to save on disk space, etc. In software development, it's a fact of life that you need to deal with the "corner cases."

The first one. If it's a document that the alias points to, the position of that document isn't really relevant - it should just be opened.

What if you're not trying to open the file? What if you're resolving the alias and then moving or renaming the file? Or deleting it? Or deleting the entire folder that the original is stored in? In cases like these, you do not want to get the wrong file by accident. The OS doesn't know what you're going to do with a path once you ask it to resolve an alias to a path, so it can't play games like this — it would be extremely dangerous.

And of course there's the fact that it's not possible to get the path from the inode anyway, since the links are one-way. It's easy to look up a file on an HFS file system by CNID, because all the B-tree keys in the catalog file are prepended by a CNID, and all you have to do is look up the file thread record whose key has the ID you want, look up the parent directory's CNID, and then use that to find the actual file record (file records have their parent directory's CNID in their keys instead of their own, so that it's easy to enumerate a directory). It's relatively fast. To do the same thing with an inode, you'd basically have to search the entire drive, looking up the inode number for each and every file until you found one corresponding to the number you were searching for. I doubt too many people would be patient enough to wait for a full hard drive search every single time the OS wanted to resolve an alias.

Perhaps. I just keep seeing these rants around the web about how HFS+ sucks and that it was silly for Apple to use it over UFS in OS X. HFS+ has it's flaws, no debate there, but there are good reasons for some of those features, and UFS is no picnic when the file directory starts being flaky (lost+found? ). All of these debates about "the Mac way" and "the Openstep way" seem to end with the Mac way losing because there aren't any old Mac heads left at Apple. If they can kill creator codes on a whim, I certainly think that they can kill aliases.

Is anyone talking about UFS? I think the way Apple is likely to go is with a new file system, either something home-brewed or something like ZFS if they can ever work out the licensing issues. In either case, Apple appears committed to alias-like functionality, given that they've been adding and improving upon that functionality lately, and making it more accessible. Just have a look at the NSURL docs and check out all the APIs that say "Available in Mac OS X v10.6 and later" to see what I mean.

[P]

Originally Posted by CharlesS 

What if you're not trying to open the file? What if you're resolving the alias and then moving or renaming the file? Or deleting it? Or deleting the entire folder that the original is stored in?

But you can't do that with an alias today! If you attempt to move the alias, or delete it, you affect the alias file and not the original. The only way to do what you suggest is to Reveal the original file in the Finder. If you select that, it's not unreasonable to offer up a list of locations to pick from.

Originally Posted by CharlesS 

In cases like these, you do not want to get the wrong file by accident. The OS doesn't know what you're going to do with a path once you ask it to resolve an alias to a path, so it can't play games like this — it would be extremely dangerous.

You're assuming a level of abstraction that isn't there. Aliases are only resolved once you attempt to open them. You are describing a situation where someone tries to delete a file and inadvertently gets an alias which then resolves to a real file, but that will never happen. If you try to delte an alias, you delete the alias - not the source file.

Originally Posted by CharlesS 

And of course there's the fact that it's not possible to get the path from the inode anyway, since the links are one-way. It's easy to look up a file on an HFS file system by CNID, because all the B-tree keys in the catalog file are prepended by a CNID, and all you have to do is look up the file thread record whose key has the ID you want, look up the parent directory's CNID, and then use that to find the actual file record (file records have their parent directory's CNID in their keys instead of their own, so that it's easy to enumerate a directory). It's relatively fast. To do the same thing with an inode, you'd basically have to search the entire drive, looking up the inode number for each and every file until you found one corresponding to the number you were searching for. I doubt too many people would be patient enough to wait for a full hard drive search every single time the OS wanted to resolve an alias.

It wouldn't do that every time you resolve an alias, it would only do that when you tried to reveal a file. If you only want to open the file, you don't need the path. Revealing is the exception, and yes it would take time, but it's a rare occurrence.

Originally Posted by CharlesS 

Is anyone talking about UFS?

In rants about how HFS sucks. Not as a serious alternative, no, but look at some of the reviews of 10.0 and you'd see all the pundits betting on UFS being the default future FS.

Originally Posted by CharlesS 

I think the way Apple is likely to go is with a new file system, either something home-brewed or something like ZFS if they can ever work out the licensing issues. In either case, Apple appears committed to alias-like functionality, given that they've been adding and improving upon that functionality lately, and making it more accessible. Just have a look at the NSURL docs and check out all the APIs that say "Available in Mac OS X v10.6 and later" to see what I mean.

What I think Apple will do is take a long hard took at BtrFS and then make "HFS 3" (referred to as Mac OS Extreme in Disk Utility) based on that. ZFS is cool, but most of it's features are pointless from Apple's perspective. As an option in a server setup it's fine - excellent - but for the boot FS on the latest MBP? No.

[CharlesS]

Originally Posted by P 

But you can't do that with an alias today! If you attempt to move the alias, or delete it, you affect the alias file and not the original. The only way to do what you suggest is to Reveal the original file in the Finder. If you select that, it's not unreasonable to offer up a list of locations to pick from.

I am referring to operations done to the original file after resolving an alias, not operations done to the alias file. Indeed, I haven't been referring to alias files in the first place.

You're assuming a level of abstraction that isn't there. Aliases are only resolved once you attempt to open them. You are describing a situation where someone tries to delete a file and inadvertently gets an alias which then resolves to a real file, but that will never happen. If you try to delte an alias, you delete the alias - not the source file.

This is not true. Aliases/FSRefs/Bookmarks (I've been using the term "alias" somewhat broadly) are resolved at any time a program wants to use them. This includes every time a Carbon app does anything with any file on the disk, since the Carbon file system APIs are all FSRef-based, any time a Cocoa app does anything with a file that it's opened or saved through the NSDocument mechanism since it uses some sort of FSRef/alias based solution internally, any time a Cocoa app uses the new Snow Leopard file reference NSURLs with the NSURL-based APIs, and any time a conscientious Cocoa developer uses either his/her own hand-rolled alias functionality or one of the various existing alias frameworks in order to get the UI benefits (Pacifist, for example, makes use of aliases internally). Don't believe me? Open a file in TextEdit, then go to the Finder and rename it, and then go back to TextEdit. See how the name changed in the title bar? Aliases are being resolved on your system pretty much every time you do anything. Their behavior needs to be deterministic, or else you will unleash unspeakable carnage on your system. The lookup also needs to not be a 15-minute process for the obvious reasons.

It wouldn't do that every time you resolve an alias, it would only do that when you tried to reveal a file. If you only want to open the file, you don't need the path. Revealing is the exception, and yes it would take time, but it's a rare occurrence.

You are assuming that opening or revealing an alias file in the Finder is the only time an alias or FSRef ever gets resolved. I can assure you that said Finder operations are an almost infinitesimal minority of cases. And even if this were not so, you do need the path in order to open a file, because applications need to know the location of the file they're opening - it's an expected parameter, and it's needed in order to implement things like safe saving, as well as being needed for any open/save operations that aren't simple (un)archive to/from data type cases. Passing a reference to the app is fine, but not if said reference takes 15 minutes to resolve and is unreliable even then.

In rants about how HFS sucks. Not as a serious alternative, no, but look at some of the reviews of 10.0 and you'd see all the pundits betting on UFS being the default future FS.

That was almost ten years ago.

What I think Apple will do is take a long hard took at BtrFS and then make "HFS 3" (referred to as Mac OS Extreme in Disk Utility) based on that. ZFS is cool, but most of it's features are pointless from Apple's perspective. As an option in a server setup it's fine - excellent - but for the boot FS on the latest MBP? No.

ZFS's features would offer a massive improvement to things like Time Machine. Its improvements to general reliability would be great for pretty much all uses. Unfortunately, you do seem to be correct that we won't see it, but most likely due to licensing issues rather than technical ones.

[P]

Originally Posted by CharlesS 

Aliases/FSRefs/Bookmarks (I've been using the term "alias" somewhat broadly) are resolved at any time a program wants to use them.

And I haven't. I meant alias files - they can be implemented by pointing to inodes. I agree that there is a problem implementing FSRefs and Bookmarks using inodes.

Aaaand...that was all of the debate, really. Right?

[CharlesS]

Well, almost. The same problem in implementing FSRefs and bookmarks exists in implementing aliases, since aliases are just another internal structure used to keep track of files. And since an alias file is nothing more than just a serialized representation of an alias, all the same problems in implementing an alias also applies to the alias files. The only thing that restricting the scope like that accomplishes is to cause the problems to crop up less often since you're now describing a rarer operation. Doing a full drive search only when someone double-clicks an alias is certainly better than doing full drive searches any time any application does anything, but it's still not good. The fact of the matter remains that inodes are a to-many relationship with one-way links, and thus are neither intended nor well-suited for the sort of thing that CNIDs are used for.

I do consider this discussion to be over since I've said pretty much all that I think needs to be said on the topic at this point.

[P]

Almost. My point is that you don't need to do a full drive search when someone doubleclicks an alias, because you can open the file using the inode number. You'd only need the full drive search when anyone did reveal, which is rare.

[CharlesS]

Originally Posted by P 

Almost. My point is that you don't need to do a full drive search when someone doubleclicks an alias, because you can open the file using the inode number. You'd only need the full drive search when anyone did reveal, which is rare.

Except that that won't work, because applications need to have a reference to an actual file system object in order to open it, not just an inode. They will use this object to do everything from figuring out the filename to put in the window title bar to determining the icon, to figuring out what parent folder to display if you right-click on the title bar, to figuring out where to atomically save the thing when you save it, to figuring out where to put the autosave file if there is one. NSDocument makes use of all sorts of features that require the original file system object, so you can rule out pretty much any Cocoa apps from working with this. You can also rule out any apps that use a non-traditional method of opening the file which depends on the path, such as passing the file to a third-party library whose APIs take a path as input (Pacifist does this, with libxar) or passing a file to an external command-line program (Pacifist does some of this too, with lsbom and pax). Overall, I'd guess there might be two or so applications on the entire platform for which this opening a file straight from an open file descriptor would be a feasible solution, if that. And then you'd have the problem of the Finder not knowing what application to open the file with without knowing the extension. This simply would not work, sorry. Inodes do not do the same job that HFS CNIDs do.