If you refer to a file by an inode you are basically creating a hard link so if the file is deleted the file still 'exists'.
Also you cannot get a file path from an inode thus if the file path is changed (moving a file for example) the application cannot know what the new path is.
A FileID is really more equivalent to a path, or rather used in place of a path with the advantage that the path can change and the fileID remains the same. Thus referring to a FileID is less fragile.
Also FileIDs are smaller so searching for files using a FolderID or FileID is faster and uses less memory.
The process could be delayed until the disk isn't being used. The file would still use twice as many blocks but with today's hard drives that shouldn't be a problem.
As for Linux filesystems they don't support FileIDs so who cares |-)
A better solution is to end all self-funding activity by such agencies. All money ought to be appropriated by the legislature like the constitution says.
1) Yes it does, break it
2) Fuck POSIX |-)
I'll take usability over some standard which is easy to work-around.
UFS on MacOS X is also very slow and your Aliases will break when the original file is moved or renamed.
A more technical explanation: http://developer.apple.com/technotes/tn/tn1150.htm l
You can but it's SLOOOOW
http://www.cocoadev.com/index.pl?FileID
If you refer to a file by an inode you are basically creating a hard link so if the file is deleted the file still 'exists'.
Also you cannot get a file path from an inode thus if the file path is changed (moving a file for example) the application cannot know what the new path is.
A FileID is really more equivalent to a path, or rather used in place of a path with the advantage that the path can change and the fileID remains the same. Thus referring to a FileID is less fragile.
Also FileIDs are smaller so searching for files using a FolderID or FileID is faster and uses less memory.
They're not equivalent.
If Apple got rid of HFS+ they would need to replace it with something else. No other filesystem supports FileIDs for example.
Time for HFS++
The process could be delayed until the disk isn't being used. The file would still use twice as many blocks but with today's hard drives that shouldn't be a problem.
As for Linux filesystems they don't support FileIDs so who cares |-)
I'd still like to defragment larger files even if it's done manually. Plus Optimizer requires a reboot.
Your "solution" sucks ass.
A better solution is to end all self-funding activity by such agencies. All money ought to be appropriated by the legislature like the constitution says.
Apply this to the local police too.
The best thing about HFS+ for me is FileIDs. I don't think a single other filesystem supports them.
I would have thought "Theory and History" would have been a more appropriate link |-)
I could have done without the editorial.
I'm surprised you didn't mention other thoughts in your head, like whether or not you like twinkies.
Gee, just think what if gcc was compiled with xlc! /giddy
Duh.
But not with the original processor. 10.1 worked with the original processor, with 10.2 you have to upgrade to a G3/G4
I highly doubt the 10.2 kernel will run.
BTW this isn't something special OpenDarwin does. Apple's standard 10.1 kernel works on Macs without G3 processors, no thanks at all to OpenDarwin.
Is that based on the 10.2.6 kernel or some ancient 10.1 kernel?
To my knowledge 10.2 kernels don't work on Macs with pre-G3 processors.
Oh great, maybe next time they'll bring an IMAX camera so I can see moon rocks in high def.
Woop de friggin DO
'cause not a single Qt app does so far
SCO or FSF?
Seriously guys, the way to beat childishness is seriousness.
We can always use BSD |-)
I don't know why that last word was left out of the title
DU is almost as radioactive as natural uranium. It is VERY radioactive!
Uh huh. Are you even going to change the file i/o so it uses FSRefs and AliasHandles instead of file paths?
I mean c'mon really, all you're doing is changing the appearance, NOT the behavior.
Using Qt does not make your app follow the human interface guidelines, nevermind various mac conventions which aren't mentioned in the guidelines.