Add File Archive Event (+ other file actions)

[Sharpiro]

Type: Feature request/Question
NLog version: 4.2.3
Platform: .Net 4.5

• Why do I/We need it?

My requirement is that I need to be able to know exactly when that file has been successfully copied over to the network directory so that I can then either begin using it or perhaps move it to another directory on the same drive that holds completed archived files. The goal is to ensure that no file is touched that is still in progress of being copied over, which is more likely in the event of an unusually large log file.

I was wondering if there is currently any way to determine if a file being archived to a remote directory has completed copying over, perhaps an event that could be subscribed to. If not, is there a workaround, or would this be a good idea for a feature request?

[304NotModified]

Hi,

there aren't events right now. Also the needed methods aren't virtual. So the only option for a work around would be: copy the class and add it.

We do like the events idea. I think it's then important to add a more events like when deleting a file, etc. Do you agree?

[sliekens]

File action events would also be great for when LayoutWithHeaderAndFooter is too limited. I would love to be able to write header and footer log messages from application code instead of having to statically define a header/footer layout.

[304NotModified]

@StevenLiekens You can use (limited) layout renderers in footer /header. And I would write my own target wrapper in your case.

[304NotModified]

If we like to boost this, please propose a list of events we need to implement.

[farukhsharipov]

+Add event when file is being rolled.

[304NotModified]

if we like to boost this, please propose a list of events we need to implement.

;)

Sorry, busy with other NLog stuff

[snakefoot]

Note that the pending #1993 includes a heavy refactoring of the FileTarget archiving logic (But doesn't include an archiving event-notifier)

[adyshimony]

I can help with it, but we need first to decide if this is the best solution to our project.

I suggest the following events:

LogBeforeArchiveEvent - when the main log reach the size limit / day limit.
LogAfterArchiveEvent - when the main log is archived.
MaxArchiveReachedEvent - we have reach max archive number.
ArchiveFileDeleteEvent - when the first archive clear the space for the new ones.

[farukhsharipov]

@adyshimony events look good! Anyone else has any suggestions or comments?

[304NotModified]

+Add event when file is being rolled.

Which events will be triggered in this case?

Anyone else has any suggestions or comments

So 4 events in total? I think "log" could be removed from the event names?

[adyshimony]

+Add event when file is being rolled.
Which events will be triggered in this case?

I think that this event covers it:
LogAfterArchiveEvent
We only need to know that the main log is archived (or before archiving - LogBeforeArchiveEvent )
Can it be that there is a roll without archive?

Also I think we can add BeforeDeleteLogEvent (when DeleteOnClose is true)

[farukhsharipov]

@304NotModified
I was looking for
LogAfterArchiveEvent - when the main log is archived.

[304NotModified]

OK, then I guess this list is complete :)

LogBeforeArchiveEvent - when the main log reach the size limit / day limit.
LogAfterArchiveEvent - when the main log is archived.
MaxArchiveReachedEvent - we have reach max archive number.
ArchiveFileDeleteEvent - when the first archive clear the space for the new ones.
BeforeDeleteLogEvent

I think it's good idea to keep everywhere a before and after event.

I also propose the following names:

1. BeforeArchivingEvent - when the main log reach the size limit / day limit.
2. AfterArchivingEvent - when the main log is archived.
3. MaxArchivesReachedEvent - we have reach max archive number.-
4. BeforeDeletingArchiveEvent - when the first archive clear the space for the new ones.
5. AfterDeletingArchiveEvent - when the first archive clear the space for the new ones.
6. BeforeDeletingEvent
7. AfterDeletingEvent

Another option for the name would be: drop before/after and name it like ArchivingEvent and ArchivedEvent

[farukhsharipov]

@304NotModified I like Before\After naming it makes in a little more explicit. While ArchivingEvent leave room for speculation, is it before, after or even during event...

[snakefoot]

An excellent case for making use of the archive events is to implement #2732 (Allowing the FileCompression to become a background task, that can also handle bulk compression of multiple files).

[Brondahl]

Would be keen on this functionality being added. Looks like it hasn't been touched for a while, though.
Is that just a question of resources and prioritization? Or is there uncertainty about whether this feature is appropriate?

[304NotModified]

Priority indeed but also the filetarget is a bit large now (in code and functionality).

[Brondahl]

If you could reach a conclusion about whether you want to extend fileTarget, then I would probably be up for doing the dev work for this. (I've got a short list of other partly-in-flight OS work that I should probably tie up first though! 😅 )

[304NotModified]

@snakefoot what's your opinion on this? I think we should target NLog 5 for this? (dev branch)

[snakefoot]

It would make sense to have a super-cool guy/girl to setup a great notification-framework, that also allows one setup additional archive-logic. That allows a wrapper to hook into the filetarget events. See also #2732 + #2296 + #1314

But the NLog FileTarget has so many specialities, so making a clean cut that makes it possible to have events where FileStream is open for read / write / delete / etc. (might need extra thought).

Also together with the wish of extracting some of the more exotic logic like mutex / file-watcher-logic to add an advanced concurrent file-target.