Rolling log files not stored in same place

[uabiarb]

I am running a licensed version 8.3.1 of SecureCRT. I have configured my log files to store to "...SecureCRT\Logs\%F\%S_%M-%D-%Y.txt". I have 'Start log upon connect' and 'Start new log at midnight' both selected, and I have the 'Append to file' mode selected. My initial log files are being properly created, and stored in the sorted directory "%F" referenced above in the path. However, when the new log file rolls over at midnight, it is not being created in ...\Logs\%F\..., it is being stored a level above in the '...\Logs\' directory. Am I doing something wrong, or have a missed a setting to ensure that the rolling log file still gets created in the nested ...\Logs\%F\ directory?

[bgagnon]

Hi uabiarb,

I cannot replicate that issue in the current, official release, v8.7.2.

I also could not replicate it in v8.3.1. Both logs ended up in "…\Logs\%F" subfolder. What OS is SecureCRT installed on?

Nothing about the folder structure is changed before the next day rolls around, right?

Does your license give you access to v8.7.2? (Please DO NOT post the serial number here, if you are not sure, please send in the body of an email to support@vandyke.com and reference Attn Brenda - Forum Thread #14242.)

If you can upgrade to v8.7.2, then we will need to get trace options output. Since that can contain sensitive data (at least the more verbose form, which we need to capture), I suggest taking this out of the public forums in either case (use email details above).

[uabiarb]

I am running it on Windows 10.

The directory is in a mounted local network storage, hence my removal of the prefix in my initial post. No, that directory structure does not change. It is a user directory, and I am not changing it at night. An analogous path would be "X:\uabiarb\SecureCRT\Logs\%F\%S_%M-%D-%Y.txt"

I have just updated to 8.7.2. I can start a session with a keep alive and test this tonight as the day rolls over, and I will let you know.

[uabiarb]

Unfortunately, apparently our IT department decided to push out some update last night without warning or notification, so my test session was interrupted, and I am unable to confirm whether this resolved the issue or not. I will retest tonight and confirm results when I can.

[bgagnon]

Hi uabiarb,

No, that directory structure does not change.

Note that I am not referring to the network share, but instead the folder structure within Session Manager since that is what %F is providing. (In other words, did the session get moved into a folder "one level up" before midnight rolled around?)

No rush, just let us know the results in v8.7.2. If you still get these odd results we will have to increase trace options output and so I will need you to contact us directly as indicated in the prior post.

[uabiarb]

The issue persisted today. An email has been sent to continue this.