NVDA Log Files should be identifiable both by version that created them and, for portable or "running from installer" versus installed

[britechguy]

Is your feature request related to a problem? Please describe.

At the moment, NVDA, whether portable, running from installer, or running as installed all use %TEMP% as the location for both nvda.log, and nvda-old.log.

When attempting to diagnose issues using older versions of NVDA, run as portable or from installer, as well as running whatever the latest installed version happens to be, this results in each one respectively "clobbering" the nvda.log of the other and, potentially, even the nvda-old.log.

Describe the solution you'd like

I would like to see the generic nvda.log, and nvda-old.log, additionally identified with the version of NVDA that created them, as well as "how they were run" if the latter is practical, and I have to believe it would be.

I would far sooner see nvda2023.beta3_installed.log or nvda_2023.1_portable.log or nvda2023.2_installer.log, and the same thing for their respective -old equivalents. It makes it immediately clear what version of NVDA generated the log as well as how that particular run of NVDA was performed.

Describe alternatives you've considered

None

Additional context

N/A

[YetiAnt]

I often use NVDA to examine software accessibility. The date and time of the creation of a log would also be very helpful. So I would like the name nvda2023.beta3 installed.log 20231001 0524; where the numbers at the end represent the timestamp of the start of the instance. . Of course, it would still have to be ensured that endless log files do not accumulate. a bot could delete all logs older than ?24 hours? when starting NVDA.

[britechguy]

I certainly wouldn't object to date-time being added to the name of the log file.

[AbhishekSRaut]

@britechguy, I respectfully hold a differing perspective on this matter. Whether NVDA is executed as a portable or installable application, the fundamental system behavior remains unchanged. Log files are consistently saved in the %TEMP% directory. In this setup, when NVDA is restarted, the previous logs become "nvda-old.log," and the newly generated ones are "nvda.log." It's crucial to recognize that developers primarily focus on the log content rather than file names. The log entries already include version numbers and relevant information. In essence, there are only two files to manage, and the distinction is relatively straightforward. The decision to name log files differently can be left to individual users. For instance, if you are running NVDA 2023.3 beta and believe that separate logs are necessary, you can manually copy and rename these files as you see fit. Regarding the installable and portable versions, there is virtually no distinction other than the configuration directory, which is already documented within the log files. In summary, while I understand the desire for more elaborate log file names, the existing system is generally practical, with log content being the primary concern for developers. However, flexibility in naming can be left to user discretion.

[YetiAnt]

Desires are one thing, feature requests are another. I'm sorry that I didn't give sufficient consideration to the issue of security :-(

[beqabeqa473]

I don't think it is a thing to even beeing considered.

As Abhishek already stated, all needed information is already in the log so i'd personaly vote against any change. No need logs to be scattered.

On 10/1/23, Yeti @.***> wrote:

Desires are one thing, feature requests are another. I'm sorry that I didn't give sufficient consideration to the issue of security :-(

-- Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/15555#issuecomment-1741992606 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

-- with best regards Beqa Gozalishvili Tell: +995593454005 Email: @.*** Web: https://gozaltech.org Skype: beqabeqa473 Telegram: https://t.me/gozaltech facebook: https://facebook.com/gozaltech twitter: https://twitter.com/beqabeqa473 Instagram: https://instagram.com/beqa.gozalishvili

[Brian1Gaff]

No, in portable versions they are in a sub menu of the folder you put the program into. This is also why there should be no changes as it makes it very easy to drop a batch file into each folder to grab the old log and load it into notepad. Thus if every version you are testing is in its own folder then where is the problem. I'm sure the security in windows would complain bitterly if the info in the user config of a portable version was going to ask to be saved in app data folders. Brian

-- @. Sent via blueyonder.(Virgin media) Please address personal E-mail to:- @., putting 'Brian Gaff' in the display name field.

[britechguy]

I'm sure the security in windows would complain bitterly if the info in the user config of a portable version was going to ask to be saved in app data folders.

And, yet, they are. We just went through this, at length, yesterday on the NVDA group, which is part of what triggered my request. See topic: 2 bugs found in latest Beta 3

If you want to argue with Rui Fontes, myself, Sarah Alawami, & Luke Davis about where we find our nvda.log and nvda-old.log files stored, no matter what NVDA "run type" we're using, have at it.

@beqabeqa473: I have no idea what you're talking about with logs being scattered. I proposed log file names that give a clear indication of their exact genesis. I did not propose having them in any folder location other than %TEMP%

@AbhishekSRaut : You believe that this setup is "generally practical" and I absolutely, positively do not. It requres gyrations on the part of users that should not be necessary, and makes their participating in the debugging process more complicated than it need be.

[CyrilleB79]

Although not exactly answering to this request, NVDA Dev & Test Toolbox add-on allows to save a configurable number of logs timestamped with date/time.

Of course the add-on does not replace a built-in feature; and in case of assistance, it's interesting to have the feature directly built in NVDA. But the add-on can be a source of inspiration.

If more than two logs (nvda.log and nvda-old.log) are saved in %temp%, we should ensure that an assisted user will be able to find and send the appropriate log. Giving instructions such as "Send us nvda-old.log and nvda.log" are clearer and more universal; but in the case of various versions of NVDA (portable, installed, etc.) I acknowledge that it can lead to confusion.

[Brian1Gaff]

@echo off cd "%temp%" start /WAIT nvda.exe -q

start notepad.exe nvda.log rem, this line just kicks its heels for a bit to make sure the log is loaded into notepad before rebooting nvda. ping -n 5 127.0.0.1>nul start nvda.exe

exit

How about the above shoved somewhere and run to reboot your stable version and loading the log of the other version into notepad?

-- @. Sent via blueyonder.(Virgin media) Please address personal E-mail to:- @., putting 'Brian Gaff' in the display name field.

[britechguy]

@Brian1Gaff

While I understand your script, even is not necessary, strictly speaking, in many instances. If it's only 2 successive invocations of NVDA, the latest one would be logged in nvda.log, and the immediately prior invocation would still be available in nvda-old.log.

This entire feature request has arisen out of what one has to do in order to adequately test issue #15554, which arose out of work I was doing for issue #15397. In the situation that was going on, there was no way to adequately test this without invoking the NVDA installer instance without using a command line and LOGFILE switch. I doubt that this has been, or will be, the sole instance where this is the case. Hence, this feature request.

[seanbudd]

See also #12621