Verily I say unto thee that Snit spake thusly:
> On 8/19/12 5:12 AM, in article
201208191...@usenet.drumscum.be,
> "TomB" <
tommy.b...@gmail.com> wrote:
>>
>> Aliases are an OSX thing, right? Are they functionally identical to
>> symlinks?
>
> No, they are more like Windows "shortcuts" though they do not break
> when you move files.
That would make it a "hard link", except it seems OSX "aliases" can in
fact be broken, and therefore they're actually "soft links".
[quote]
If you delete the file to which an alias is linked or move or modify the
file so that the alias can no longer locate it, you will get an error
message when you double-click the alias file. This message will state,
"The alias {name of file} could not be opened because the original item
could not be found." This situation is called a broken alias.
At this point, you can click OK (thereby ignoring the issue for the
moment), Delete Alias (with the obvious result), or Fix Alias. This last
option opens a window similar to what appears when you click Select New
Original in the Show Info window. From here, you can navigate via a
directory window to the desired destination file and select it as the
destination for the alias.
...
Aliases are linked to the file or folder to which they point. If you
move the original file to a new location, the alias is able to keep
track of this situation and maintain the link. When you double-click the
alias, the original file still opens.
[/quote]
IOW the OS (via FSEvents - formerly a private API) is tracking file
operations and updating soft links (or "aliases", as Apple calls them)
as needed, but if you move or delete the source file using the CLI or
any app that doesn't use FSEvents, then the "link" is broken, because
that "link" isn't really a link at all, it's an entry in a secondary
application's log file, which in this case will not have been updated.
And if fseventsd /itself/ stops functioning, for whatever reason, all
subsequent filesystem events will remain unrecorded, thus breaking all
subsequent "aliases" (assuming OSX will then allow any "aliases" to be
created at all).
Meanwhile, this is how a proper hard link works on a real filesystem:
~ % mkdir foo1 foo2
~ % touch foo1/bar
~ % ln foo1/bar foo2/bar
~ % echo "Hello World" >>foo1/bar
~ % cat foo2/bar
Hello World
~ % mv foo1/bar foo1/snafu
~ % echo "Hello again" >>foo1/snafu
~ % cat foo2/bar
Hello World
Hello again
No "FSEvents daemon" required. The filesystem itself keeps track of the
link.
In fact I can now completely delete the original, and the linked file
remains intact, since both the original and the linked file were just
pointers to the same block of data on the filesystem.
~ % rm -f foo1/snafu
~ % cat foo2/bar
Hello World
Hello again
Only once the last remaining pointer to that block of data has been
unlinked will the file be "deleted", although the data itself remains
(unreferenced), and can be recovered if you know its inode number (using
debugfs and dd), unless that block is explicitly wiped or overwritten.
But OSX's support for hard links is little more than a retrofitted
kludge:
[quote]
NSDocumentController controls all documents in OS X (together with
NSUserDefaults). When running on HFS+, it creates records which rely on
HFS+ catalog file information.
...
It is for this reason that a Cocoa document can know immediately when a
file name has changed: the _NSAlias lets NSDocumentController
'backtrack'.
But this system also assumes there is but one file name for physical
storage on disk. If the file becomes multi-linked, the old file record
is moved to \0\0\0\0HFS+ Private Data and a new file record (of a new
type) is written to its own directory to replace it.
And NSDocumentController is thrown for a loop.
[/quote]
http://rixstep.com/2/20040621,00.shtml
Apparently this has been improved somewhat over the years, but it still
requires an "FSEvents daemon" to monitor filesystem changes:
[quote]
So, no, /dev/fsevents is not a good candidate for a public API. But the
demand for efficient, asynchronous file system notifications remains.
What to do? Enter Leopard's FSEvents framework. It takes a pragmatic
approach to providing these features.
This is a theme that recurs throughout Leopard's new technologies. Given
a thorny technical problem, FSEvents does not attempt to be all things
to all people. Instead, it shrewdly narrows its focus, concentrating on
the possible and the probable. FSEvents provides an "80 percent
solution" with (near) 100 percent reliability, rather than attempting to
be an all-encompassing, "perfect" solution.
FSEvents design and implementation
It seems to me that the key breakthrough in the design of FSEvents was
arrived at by considering yet another weakness of /dev/fsevents. The
private /dev/fsevents API doles out notifications in real time to all
interested clients. This appears to be the best feature of the API, but
it's actually quite a burden for clients. Any events that occur when a
client program is not running will never be seen by that client. This is
why the Spotlight indexing process is launched when the system boots and
remains running as long as the computer is on. It must do this in order
to catch and process all file system events.
...
So how does this realization lead to a design for FSEvents? The answer
is that solving the problem of the constantly running client also makes
many other problems disappear. Here's how FSEvents does it.
The /dev/fsevents API can only support a few extremely well-behaved
clients. Spotlight is one. In Leopard, FSEvents is another. The FSEvents
framework relies on a single, constantly running daemon process called
fseventsd that reads from /dev/fsevents and writes the events to log
files on disk (stored in a .fseventsd directory at the root of the
volume the events are for). That's it. That's the super-high-tech
solution: just write the events to a log file. Boring, pragmatic, but
quite effective.
Programs wishing to use the FSEvents API do not need to be running
constantly. They can be launched at any time and can ask, "Okay, what's
changed since the last time I was running?" As long as they know where
they left off in the log file, the FSEvents framework can (effectively)
"play back" every event that's occurred since then and answer the
question accurately.
Pragmatic? Isn't it also fair to call this solution "fraught with its
own intractable problems"? How big are these log files? Are they going
to fill my disk if I constantly create, modify, and delete files? Will
the log files be trimmed? What if a process doesn't run for a year and
then wants to know what's changed since then?
Pragmatism means compromise. Yes, if fseventsd drank from the
/dev/fsevents fire hose and wrote every single event to disk, you'd run
out of disk space pretty quickly. To avoid this, fseventsd only writes
out changes at the much less granular directory level. The FSEvents
framework, in turn, can only tell its clients, "Something has changed in
directory /foo/bar/baz."
[/quote]
http://arstechnica.com/apple/2007/10/mac-os-x-10-5/7/
Good grief, what a mess. No wonder Torvalds described HFS+ as "complete
and utter crap".
[quote]
Q. Do you have a favourite between Leopard and Vista?
A. I don't think they're equally flawed. I think Leopard is a much
better system. On the other hand, (I've found) OS X in some ways is
actually worse than Windows to program for. Their file system is
complete and utter crap, which is scary.
[/quote]
http://www.smh.com.au/news/technology/q-and-a-with-linus-torvalds/2008/02/05/1202090403120.html
If Apple ever finally updates its ancient filesystem to ZSF then it
might actually support hard links properly. Apparently a third-party
solution called "ZEVO" is available now, but of course you have to pay
for it.
http://macperformanceguide.com/blog/2012/20120218_1-ZFS-for-OSX.html
Why Apple hasn't integrated ZFS natively is a mystery. After all, the
filesystem itself is free (cost), and is even licensed under an
ostensibly Open Sauce license (Sun's anti-GPL CDDL).
http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License#GPL_incompatibility
Frankly I don't see why Apple can't just use ext4 or btrfs.
--
K. | "You see? You cannot kill me. There is no flesh
http://slated.org | and blood within this cloak to kill. There is
Fedora 8 (Werewolf) on šky | only an idea. And ideas are bulletproof."
kernel 2.6.31.5, up 72 days | ~ V for Vendetta.