Skip to content

close the outgoing appenders before activating the new ones #321 - #322

Draft
FreeAndNil wants to merge 17 commits into
masterfrom
Feature/322-reconfiguration-file-lock
Draft

FreeAndNil wants to merge 17 commits into
masterfrom
Feature/322-reconfiguration-file-lock

Conversation

@FreeAndNil

@FreeAndNil FreeAndNil commented Sep 19, 2026

Copy link
Copy Markdown
Contributor

Fixes #321.

- A failed rename was reported, then the file reopened without appending, which
  destroyed it. A backup agent holding a read handle is enough. It appends now,
  and only that rename is retried, once per MaxFileSize of growth, so the
  backups are never rotated twice and a retry that succeeds keeps the generation
  it recovers.
- The footer, close and open paths released the file lock even when acquiring it
  had failed. Only what was taken is released now.

audit da18b6f-f036, da18b6f-f032
- InterProcessLock named its mutex before the path was resolved, so a relative
  and an absolute spelling of one file took two mutexes and excluded nothing.
- A name over 255 characters throws on Unix, out of ActivateOptions, so a deep
  log path took the appender down. Those are hashed now. Windows has no limit,
  measured, so its names are left alone and keep excluding older versions.
- Both mutexes take their name from one helper, which carries why there is no
  ACL, no Global\ prefix and no user component.

audit da18b6f-f031, da18b6f-f010
Windows 7 SP1 is the floor for the net462 build this file compiles into, so the
version test could not fail and the 32766 constant behind it was dead. The
surviving constant keeps its measured value and loses the superseded lore.
- Release the file lock with _stream?.ReleaseLock() wherever the acquire was
  already null-conditional.
- One CountingWriter property instead of five QuietWriter casts, through
  EnsureIs<> so a wrong writer names itself. The two sites after a reopen keep
  their null check: a refused lock leaves no writer there.
- The new fixtures keep no state between tests: AutoTempFolder from
  PeanutButter.Utils and a per-test error handler. Its namespace collides with
  our test helper Utils, which is internal TestUtils now.
- SmtpPickupDirAppenderTest kept its pickup directory in a fixture field, shared
  by every test, and created it inside the build output.
- FileAppenderTest leaked two files per run: Path.GetTempFileName creates them
  and nothing deleted them.
- PatternStringTest tracked its config file by hand to delete it in a finally.

All three use AutoTempFolder now, which disposes what it made.
104 characters can be 304 bytes, and Unix rejects by bytes.
- Date mode never retried: the check sat inside the size-rolling guard.
- The startup roll fell through to AppendToFile and truncated the file.
CLAUDE.md: a logged raw string keeps its newlines, and only the first
line carries the prefix.
- the message printed 0 bytes of growth where the threshold was really 1
- the retry-count assertion allowed 2 to 19, so a wrong threshold passed it.
  Two attempts on Unix, three on Windows, and the range says which is which
- record what the mutex suffix collision costs
- drop the empty else, rewrap a long changelog line
@FreeAndNil
FreeAndNil force-pushed the Feature/322-reconfiguration-file-lock branch from cfc1317 to 1813208 Compare September 19, 2026 21:07
@FreeAndNil FreeAndNil changed the title Feature/322 reconfiguration file lock close the outgoing appenders before activating the new ones #321 Sep 19, 2026
- ExistingInit rolled again for AppendToFile=false, moving the file out from
  under the pending rename, so the first retry archived the new file under the
  previous date.
- The forced append reached AppendToFile through base.OpenFile and replaced the
  configured value. Every successful roll did this, not just a failed one, so
  RollingCombinedWithPreserveExtension now asserts it too.
- The changelog entries now describe what a user sees.
- TheDeadlineCoversTheWholeSendAndNotOneOperation timed the whole send against a
  5 s bound, and failed on a slow Windows runner at 6289 ms
- the fake transport now records which call found the token cancelled
- XmlHierarchyConfigurator activated a new appender while the outgoing
  one still held its file, so ConfigureAndWatch failed with "Unable to
  acquire lock on file"
- regression from 592d18d (#287)
- ParseAppender collects into _pendingActivations, which Configure
  drains once every logger has swapped
- the symptom is Windows only: .NET on Linux does not enforce FileShare
  within a process, so the test asserts the open/close order instead
- the entry claimed #321, which is the FileAppender reconfiguration issue,
  filed a day after this landed
- the Antora dependency work came through #320, so the id, the link and
  the file name follow that
@FreeAndNil
FreeAndNil force-pushed the Feature/322-reconfiguration-file-lock branch from 1813208 to d512f94 Compare September 21, 2026 18:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

File lock error when using FileAppender with XmlConfigurator.ConfigureAndWatch (v3.3.1)

1 participant