PFS processing

During these operations the PFS must:
  1. Call SAF's Check Access service to verify that the caller has write permission to the parent directory. If the sticky bit (S_ISVTX) is on in the parent directory's mode, the PFS must call SAF's Check2Owners service to verify that the caller is allowed to delete or rename the object.
  2. Remove the directory entry for the named object, and update the Change and Modification times for the directory.
  3. Decrement the link count in the object whose name was removed.

    If a directory is being removed, it must be empty except for the . and .. entries. The parent's link count is also decremented to account for the .. entry in the removed directory.

  4. If the object's link count goes to zero, the object itself is deleted later during vn_inactive, but the deletion is recorded for audit purposes now.

    If the object is a regular file that is not open, the space used by its data must be released now. If a regular file is still open, its data is deleted on the last vn_close. This behavior is required by POSIX.

    A POSIX-conforming PFS should set the immeddel flag in the PFSI during initialization to let the LFS know that this requirement is in force. Otherwise, the LFS must issue vn_getattr and vn_trunc during unlink() and close() in order to check the link count and free regular file data.

  5. While an inode's link count and open count both are zero, the PFS may reject subsequent operations, except for vn_readdir, which would return no entries, and vn_inactive.