Enhance 'Create Portable Copy' to use versioned folder names (eg NVDA-2025.3)
Problem Description
Steps to reproduce:
1.With NVDA Open, hit NVDA + N, T, C, then fill in the folder into which you wish to have the portable copy placed, also ensure that the checkbox for Create a new folder for the portable copy is checked. 2. Activate the Continue button.
Actual Behavior:
The portable copy is created, under the parent folder specified, but always in a subfolder named "NVDA". This means that any subsequent choice of that parent folder will result in the existing portable (if any) being overwritten, even when the noted checkbox is checked.
Expected Behavior:
The portable copy should be created under the parent folder specified, but in a folder named NVDA-{release number of running instance}. If someone happens to be re-creating a later portable copy for the same NVDA release, it's fine if a prior one for that release, but only that release, is overwritten
System configuration
NVDA Installed/Portable/Running from some other source:
NVDA Installed
NVDA Version:
NVDA 2025.3rc1
Windows Version:
Windows 11, Version 24H2, Build 26100.6584
Name and Version number of the other software in use when reproducing the issue:
N/A
Other information about your system (e.g., Make & Model, Graphics Card, etc.):
Device name BPV_Gram_16 Processor 12th Gen Intel(R) Core(TM) i5-1240P (1.70 GHz) Installed RAM 16.0 GB (15.7 GB usable) Device ID A657C2E5-3C10-4C35-AAAA-1FE53E7095D9 Product ID 00330-81620-67765-AA261 System type 64-bit operating system, x64-based processor Pen and touch No pen or touch input is available for this display
Other Questions
Does the issue still occur after restarting your computer?:
Yes
Have you tried using any other versions of NVDA to reproduce the problem? If so, please give the version number(s) and behavior(s):
If you disable add-ons, is your problem still occurring?:
Did not disable. Should be completely independent of add-ons, as they get backed up, too, if user configuration is copied.
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's Tools menu?:
Did not attempt
Hi,
I think this would fall under "feature suggestion" category, but I think this template would do. I wonder if the behavior described is documented, and if yes, @Qchristensen, any thoughts on improving it?
Thanks.
Joseph, I can't disagree that this might be considered a Feature Request rather than a bug, but to my way of thinking it resides somewhere between the two.
Since the original issue was filed I have intentionally run the COM Registration Fixing Tool and have restarted the computer as well. What I now have going on is that an initial Portable creation in a given folder creates a subfolder named NVDA. A subsequent pass with the same parent folder is creating a subfolder named NVDA_1. A third does what's logical for the progression, and creates a subfolder named NVDA_2.
That being said, I still think that this is at least somewhat misleading as you would have to fire up the portable version that resides under the NVDA subfolder or one of the NVDA_X subfolders to determine what NVDA version that portable was made from. This is really tedious, and unnecessary since NVDA knows its own version when a portable is created, and using a version-identified subfolder (with appended _X if multiples for the same version are created with the Create new folder checkbox checked) is just as easy to do as using just NVDA. It also makes more sense for when users are attempting to keep an archive/backup of their current NVDA ecosystem for any given release so that which version resides in a given subfolder is instantly known.
I have no objection to this being converted to a feature request, I just wanted to put the issue on record, and now I have.
Personally, I think an even better idea would be NVDA-version-date. For instance: NVDA-2025.3-2025_09_19_20_22_34, or something to that effect, although I do understand that could potentially be somewhat verbose or even confusing for some people.
Personally, I think an even better idea would be NVDA-version-date. For instance: NVDA-2025.3-2025_09_19_20_22_34, or something to that effect, although I do understand that could potentially be somewhat verbose or even confusing for some people.
I can't argue with that from either perspective. But realistically speaking, I don't see many people making multiple portable backups of the same NVDA version very often, and when they do, the folder in which it's created is date-time stamped if one is using the "Create new folder" option, which I always do.
I believe that "the average end user" would be entirely overwhelmed with a fully NVDA version and date-time stamp qualified folder name. The _X, where X is a digit, for subsequent portable creations for the same NVDA version does, in my opinion, work well for simple differentiation purposes.
I don't think attaching a version number is a good idea: What if the portable version inside a folder is updated? In addition, there is a relatively convenient way to determine the NVDA version: check Report toolstips in the NVDA Object Presentation settings dialog box, then browse to nvda.exe, wait for a while, and you will hear information such as publisher, version, etc.
@britechguy could you please clarify your issue? This is the behaviour I am seeing:
- Make sure there is no directory at
C:\test. - Create portable at
C:\test, with "Create a new folder for the portable copy" unchecked.- Result: There is now a portable copy at
C:\test.
- Result: There is now a portable copy at
- Create a portable copy at
C:\test, with "Create a new folder for the portable copy" checked.- Result: There is now a portable copy at
C:\test\NVDA, as well as the portable atC:\test.
- Result: There is now a portable copy at
- Create another portable copy at
C:\test, with "Create a new folder for the portable copy" checked.- Result: There is yet a third portable copy, this time at
C:\test\NVDA_1.
- Result: There is yet a third portable copy, this time at
- Attempt to create portable at
C:\test, with "Create a new folder for the portable copy" unchecked.- Result: NVDA warns me that "A portable copy already exists" and asks me if I want to update it.
- If I answer "No", the directory is untouched.
- If I answer "Yes", the portable at
C:\testis updated, and the portables atC:\test\NVDAandC:\test\NVDA_1are left untouched.
Tested with NVDA alpha-52672,32f645ca (2026.1.0.52672), but to the best of my knowledge we haven't made any changes to the way portable copy creation is handled since NVDA 2025.3.
Pinging @britechguy re: https://github.com/nvaccess/nvda/issues/18953#issuecomment-3316365480. For what it's worth, I agree with having a more descriptive name for the portable copy folder; I also agree that people usually create portable copies of previous versions they want to archive and future versions they want to preview, making version number a relevant descriptor.
@bhavyashah - I think that would be a separate feature request to this bug report about the checkbox not working