Hi again - we are using log rotation (daily) where each day might contains the date (and a sub-number for intra-day large file rotations), such as "all-2021-02-24-00.json" and "all-2021-02-23-00.json" (etc).  To make it easy to track the current log file, it maintains a symbolic link for "all.json" to the most recent log file.

I am finding if I open the symlink file, nothing appears in the log pane, whereas if I open any of the daily files, they open correctly.  I am using the same parser for both, and there are no errors messages shown.

Does LogViewPlus support symbolic linked log files?  If not, is there an approach where if can auto-select the most recent log file given a file name pattern, or do I need to close the log and open the most recent file after any rotation to tail current log entries?

Thanks!

LogViewPlus reads remote files by mirroring them locally, so the effect of accessing a symlink is going to depend on what the server does when the file is requested for download.  Apparently, in this case the data is not being transferred and you have an empty file.  Viewing the file transfer log file might help diagnose exactly what is happening here. 

Have you considered using a Directory Monitor with a merge file?  This will show all log files in the directory sorted by timestamp.

Hope that helps,

Toby

I'm sorry I wasn't clear about this.  This is all 100% Windows 10 with no network or server involved.  The app and the symlink file all reside on my local C: drive.  The symlink file can be opened (such as Notepad or VS Code) with no problems.  The File Transfer Log is empty, which perhaps is what you would expect for a local file...?  The original file, in the exact same directory, works fine.  But opening the symlnk file doesn't show anything - not even existing lines when opening it (independent of the desire to tail it).

I will checkout Directory Monitor - I didn't see that feature!

Thanks!

Thanks for the update.  This is the first time I have seen this issue and I can confirm that this is a bug.  We will take a closer look and get this fixed for the next release.  

Thanks for reporting this issue!

Toby