Package com.ultikits.ultitools.utils

Interface PosixAttributePreserver.ReplaceInPlaceListener

All Known Implementing Classes:
OfficialLanguageFiles.LoggingListener, RemoteFileOperations.WriteDenial
Enclosing class:
PosixAttributePreserver
public static interface PosixAttributePreserver.ReplaceInPlaceListener
Callbacks a PosixAttributePreserver.replaceInPlace(java.io.File, byte[], com.ultikits.ultitools.utils.PosixAttributePreserver.ReplaceInPlaceListener) caller supplies so each replace-in-place site can log accurate, resource-specific wording for exactly how the operation was declined or degraded -- this shared operation does not know or care whether target is a language catalogue or a provenance sidecar, only the caller does.

  • Method Details

    • onOperatorPinnedReadOnly

      void onOperatorPinnedReadOnly()
      target exists and none of its POSIX write-permission bits (owner, group, or other) are set for the current process -- treated as a deliberate operator hardening signal, exactly like a symlinked target. The replacement is refused; target is left completely untouched.

    • onSymbolicLink

      void onSymbolicLink()
      target is a symbolic link. writeBytes's pre-existing contract (see PosixAttributePreserver.replaceInPlace(java.io.File, byte[], com.ultikits.ultitools.utils.PosixAttributePreserver.ReplaceInPlaceListener)'s own javadoc) is REFUSE, not write-through-to-target: the replacement is declined entirely, exactly like an operator-pinned read-only file, rather than either replacing the link itself (which would silently break an operator-managed shared layout) or resolving and writing through to the link's target (which this shared operation does not attempt, for the same relative-vs-absolute-link and shared-target reasons writeBytes's own javadoc already gives).

    • onSourceAttributesUnreadable

      void onSourceAttributesUnreadable()
      A POSIX view exists for target but reading its current attributes failed -- see PosixAttributePreserver.copyIfSupported(java.io.File, java.io.File, java.lang.Runnable, java.lang.Runnable, java.util.function.BiConsumer<java.lang.String, java.lang.String>)'s own javadoc for why this is distinct from "no POSIX view at all" and must also abandon the replacement.

    • onPermissionCopyFailure

      void onPermissionCopyFailure()
      target's permission bits were read successfully but could not be applied to the staging file; best-effort only, the replacement still proceeds.

    • onOwnershipCopyFailure

      void onOwnershipCopyFailure(String ownerName, String groupName)
      target's owner/group could not be replicated onto the staging file; the replacement is abandoned.
      Parameters:
      ownerName - the owner name target is owned by
      groupName - the group name target is owned by

    • onWriteFailure

      void onWriteFailure(IOException cause)
      The atomic write or move itself failed (e.g. the filesystem filled up mid-write, or a transient I/O error during the rename). target is guaranteed untouched -- the staging file is written and moved only after every guard above has already passed, and a failure here never truncates or partially overwrites target itself.
      Parameters:
      cause - the underlying IOException