No path formats supported
See original GitHub issueIt seems the extension WriteTo.File
does not support path formats like the ‘old’ RollingFile
does. I see Specifier.cs from serilog-sinks-rollingfile and TemplatedPathRoller
which is very similar to the PathRoller
found in this project.
It seems easy to support path templating here (since the code is very similar and can be transferred), but maybe I’m missing something here; was not templating in this project intentional? If so, why?
Thanks!
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (2 by maintainers)
Top Results From Across the Web
c# - "The given path's format is not supported."
Rather than using str_uploadpath + fileName , try using System.IO.Path.Combine instead: Path.Combine(str_uploadpath, fileName);.
Read more >File path formats on Windows systems
In this article, learn about file path formats on Windows systems, such as traditional DOS paths, DOS device paths, and universal naming ...
Read more >The given path's format is not supported - Help
I found “C:\users\userID” causing the same issue and replaced it with Environ(“userprofile”), which resolved the problem.
Read more >Error: The Given Path's Format Is Not Supported
This error message is caused when a report is saved in OneDrive or OneDrive for Business, and OneDrive is not configured to synchronize...
Read more >The given path's format is not supported error during ...
Returns the names of files (including their paths) in the specified directory. Your file variable is not a single file name but a...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi Lars,
I think a customizable format is a fair feature to add, I definitely wouldn’t rule it out in the future, but doing a good job of it seems like it will be non-trivial. Needs a lot of careful analysis around filename parsing, anyway - having the sink delete files that it didn’t create is something of a doomsday scenario 😃 It would also be necessary to ensure that whatever format is used can be reliably parsed to the right resolution -
yyyy
is never going to work for a monthly rolling file, for example, and that locale doesn’t cause anything crazy to happen. Need to figure out the constraints and how we might detect problems.Serilog.Sinks.RollingFile is so widely-used I don’t think it’ll become “legacy” in the near future - we’ll encourage people to use the File package, but if someone took the lead on RollingFile there’s room for it to continue evolving. (Having the more conservative File implementation actually takes some of the pressure off of RollingFile - perhaps it can even move a bit faster now! 😃)
Hey,
Thanks for the explanation 😃 I’ll keep a close eye on the projects going forward.