I don't disagree with the below, however, you can run your mac on UFS
instead of HFS+. Since UFS hasn't been mac-ified, I'm wondering if
the below is actually true for all filesystem types.
On May 2, 2006, at 2:02 PM, Maury Markowitz wrote:
Now that the documentation section is expanding, I can make a not-
so-ill-informed comment about zfs and the Mac OS. If I'm reading
the documentation correctly, the news is unfortunately bad.
The "problem" with Mac support is that the Mac stored all of its
display-related information in the directory itself. By this I
refer to things like the icon's position within its directory
window, the "type and creator" flags that are an analog to a file
extension, and even things like window sizing, position and scroll
location for folders. The idea here was that on a floppy, which the
FS was targetted for way back when, a single pass over the flat-
file directory would give you EVERYTHING you needed to draw the
display. Given the extremely limited bandwidth, this was an
extremely practical decision, if potentially limiting.
For the interested, here's the info needed:
http://developer.apple.com/technotes/tn/tn1150.html#FinderInfo
It's a pair of four-byte strings, three 2x16-bit Points and
potentially a 32-bit Rect, and a couple of flags, the vast majority
of which are no longer used or are duplicated in zfs's directory
ZAP anyway.
Now generally the Unix nerds would suggest hanging the Mac's extra
information in the xattrs.The problem here is that zfs stores all
xattrs separately from the ZAP directory entry. So while it is
physically possible to make another ACE for the Mac info and hang
it off the xattr "inode" (ZAP), this means that drawing a window in
the Finder will require a file system walk! This just isn't going
to work, Mac users won't accept PC-slow directory displays -- I
know I wouldn't.
What I don't understand is why this disturbingly inflexible design
was chosen. Note that the ACL ACE is built in order to store up to
six entries in-line, which likely serves 95% of all cases. Why an
identical solution was not used for xattrs absolutely baffles me.
An identical six entry with overflow ACE dir would work wonderfully
for xattrs, and in this particular case, would store all the needed
Mac-related goodness.
So can anyone tell me why xattrs weren't handled in the same way as
ACLs? It smells of inside-the-box-thinking, but I'm no FS expert
and there may very well be a good reason.
And if there isn't a good reason, is it simply too late to fix
this? If xattr were moved below gid and used up the pad[4], that
would at least give us something useful.
Maury
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
-----
Gregory Shaw, IT Architect
Phone: (303) 673-8273 Fax: (303) 673-8273
ITCTO Group, Sun Microsystems Inc.
1 StorageTek Drive ULVL4-382 [EMAIL PROTECTED] (work)
Louisville, CO 80028-4382 [EMAIL PROTECTED] (home)
"When Microsoft writes an application for Linux, I've Won." - Linus
Torvalds
_______________________________________________
zfs-discuss mailing list
[EMAIL PROTECTED]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
