Skip to content

File-sink-reopen ​

Reopen a FileSink. This helper is useful for direct recovery flows after file unavailability or after file policy changes.

Interface ​

moonbit
pub fn FileSink::reopen(self : FileSink, append~ : Bool? = None) -> Bool {

input ​

  • self : FileSink - File sink that should be reopened.
  • append : Bool? - Optional append-mode override used for reopen behavior.

output ​

  • Bool - Whether reopen succeeded.

Explanation ​

Detailed rules explaining key parameters and behaviors

  • append=None preserves the sink's current append policy.
  • Some(true/false) overrides append mode for this reopen and updates the stored append policy.
  • If a handle is currently open, the method closes it before attempting reopen.
  • On reopen failure, open_failures is incremented and the sink remains unavailable.

How to Use ​

Here are some specific examples provided.

When Need Recovery After File Failure ​

When direct file logging code should attempt to restore sink availability:

moonbit
ignore(sink.reopen())

In this example, the sink tries to reopen using its current append policy.

When Need Explicit Append-mode Reopen ​

When recovery should choose append or truncate behavior explicitly:

moonbit
let ok = sink.reopen(append=Some(true))

In this example, reopen behavior is directed by the call site.

Error Case ​

e.g.:

  • If reopen fails, the method returns false and increments open_failures().

  • If callers only need the current configured policy with no one-off override, reopen_with_current_policy() may be the clearer API.

Notes ​

  1. Use this helper for direct recovery flows.

  2. Pair it with is_available() and failure counters when diagnosing reopen behavior.

Published from the repository docs folder with VitePress.