How do I determine logfile path which is being written to?

[JoeMooreBrk]

As a user, sometimes I have trouble finding where the programmer directed the log (it was so obvious to him/her). As a programmer, I would like to give a message to the user on error where to find a log with more information. I may be missing it, but I don't see how to expose the path name of the current log file as information is being logged. Thanks!

[cocowalla]

Information about sinks isn't exposed at runtime, so I think your best bet would be to capture the directory name at startup when you're configuring the logger. For example, if you're configuring from appsettings.json, you can read the path from there.

[nblumhardt]

See also: #129 - the hook approach might also be an option to consider.

[cocowalla]

@nblumhardt while you could use the OnFileOpened hook to get the active filename, rather than just the directory, there are some big caveats (mentioned in #129). What do you think about WriteCountingStream exposing the filename of the underlying FileStream? I'm a bit unsure about this myself, since WriteCountingStream is essentially an implementation detail; OTOH, this is specifically a file sink, so maybe WriteCountingStream should be extending FileStream rather than just Stream?

[nblumhardt]

Ah, thanks! Forgot about that hitch.

I'd be more inclined to pass the filename as an additional argument to the hook method, in case we want to use different stream types in the future - I remember that this was of limited use to hooks that need to reopen the file, but it could be a reasonable step forwards (and is fairly straightforward to implement in a backwards-compatible way). What do you think?

[JoeMooreBrk]

Thanks for the quick consideration. I like the idea of exposing it there. Of course, my program does save it where I CreateLogger, but I've been around enough to know that when I maintain legacy code it's sure nice to find out what's *currently* being used by a class. Let me know if you implement something through this thread!

…

On Wed, Jun 17, 2020 at 5:43 PM Nicholas Blumhardt ***@***.***> wrote: Ah, thanks! Forgot about that hitch. I'd be more inclined to pass the filename as an additional argument to the hook method, in case we want to use different stream types in the future - I remember that this was of limited use to hooks that need to reopen the file, but it could be a reasonable step forwards (and is fairly straightforward to implement in a backwards-compatible way). What do you think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIXCXETC6LNJ2EVFPP3J3TRXFBKHANCNFSM4OA4WKVA> .

[cocowalla]

@nblumhardt yes, with hooks being the extensibility point, I think it makes sense to provide the filename there. Only question was whether it should be through a FileStream, or an additional string; string is the most flexible, as you say.

Do you mean to change the signature of the existing OnFileOpened hook, so that:

public virtual Stream OnFileOpened(Stream underlyingStream, Encoding encoding) => underlyingStream;

would become:

public virtual Stream OnFileOpened(Stream underlyingStream, Encoding encoding, string path) => underlyingStream;

Technically a breaking change, as hooks would need to be updated, but because the hooks mechanism is still quite new, I'm not sure if it's a big deal.

Happy to make the change once we're aligned on what exactly it should be 😄

[nblumhardt]

Roughly, yes 👍 - I'd probably put the path parameter first, but that's probably a bit of a bikeshed :-)

The change doesn't need to be breaking - we can add the new signature, give it a default implementation that calls the old signature without passing path, and mark the old version with [Obsolete] to encourage implementers to move over to the newer one - does that sound workable?

[syonip]

Also need a way to open the current log file at runtime.

[Grendizr]

I tried the hook approach in order to get the current log file location on disk, but as soon as I add the hook in my appsettings.json, the logs are not flushed into the file anymore.

   public class SerilogHooks
   {
        public static SerilogFileCycleHook FileCycleHook => new SerilogFileCycleHook();
   }

    public class SerilogFileCycleHook : FileLifecycleHooks
    {
        public string CurrentLoggingFilePath { get; private set; }        

        public override Stream OnFileOpened(string path, Stream underlyingStream, Encoding encoding)
        {
            CurrentLoggingFilePath = path;

            return base.OnFileOpened(path, underlyingStream, encoding);
        }
    }

While debugging I can see the hook is initiated and I can get the log file path ... but as the file stays empty now, this is not very useful ;)

Any chance we could get a bit more easily the current log file location ?

I am using Serilog 2.1 with Serilog.Sinks.file 5.0.0

Thanks

[augustoproiete]

@Grendizr We have a number of tests covering hooks usage and overall it's very unlikely that we would have a bug so basic as the one you are describing - as that would make hooks completely unusable.

You must have one or more bugs in your own code, causing the file to be empty.

For a start, it looks like you have a bug here:

public class SerilogHooks
{
    public static SerilogFileCycleHook FileCycleHook => new SerilogFileCycleHook();
}

You're creating a brand new instance of SerilogFileCycleHook every time you access this property, so surely that means Serilog is getting one instance, and when you go check it you're getting a completely different instance - This might be related to the odd behavior you're seeing.

You probably meant to write:

public class SerilogHooks
{
    public static SerilogFileCycleHook FileCycleHook { get; } = new SerilogFileCycleHook();
}

Anyway, for Serilog usage troubleshooting please post questions on StackOverflow under the Serilog tag.

If you really think you found a bug, provide a minimal reproducible code sample.

[nblumhardt]

Hi! We're triaging issues in this tracker and the current one appears to be stale. If your issue relates to a usage question, asking on Stack Overflow and posting a link here will get the most eyes on it (only a small number of maintainers actively track this repository). If your issue relates to a possible bug that still needs attention, please feel free to comment/request reopening. Thanks!