Initial resource fork handler creates many empty resource forks

[evansus]

Doesn't seem to cause any major issues, but does increase disk IO and leaves empty resource forks on many files. Can be seen by ls -alO. Seems to be most common with boot from ZFS dataset.

Currently any access of the resource fork creates an empty fork to return to the caller. Perhaps we could create an in-memory resource fork, then only write to disk when modified.

[lundman]

I guess it is related to the code here

    /*
     * If the lookup is NS_OPEN, they are accessing "..namedfork/rsrc"
     * to which we should return 0 with empty vp to empty file.
     * See hfs_vnop_getnamedstream()
     */
    if ((error == ENOATTR) &&
        ap->a_operation == NS_OPEN) {

        if ((error = zfs_get_xattrdir(zp, &xdvp, cr, CREATE_XATTR_DIR)) == 0) {
            /* Lookup or create the named attribute. */
            error = zfs_obtain_xattr(VTOZ(xdvp), ap->a_name,
                                     VTOZ(vp)->z_mode, cr, ap->a_svpp,
                                     ZNEW);
            vnode_put(xdvp);
        }
    }

Which was an attempt to get fonts to work, but since it didn't, perhaps the best idea is to retire it.. I do not fully understand what hfs_vnop_getnamedstream() does.