Is it me, or is Maximum Number of Backups not respected? In configuration under file handling -> backup I have Version Backup set to On Save with Maximum Number of Backups at 10. As I save my backup files far exceed 10 versions. Am I just using it wrong? or making wrong assumptions about how it should work?
First when using version backups the Format string must contain $c or version backups are not created.
Second you might think the counter in the filename is 0-9 when you set it to a maximum number of 10. But this is not true.
When you open a file, UltraEdit sets the version backup counter for this file always to 0. On every save the counter is increased by 1. After 10 saves you have file 0-9. On 11th save the counter in the filename for next version backup is 10 and additionally the file with the counter 0 in the filename is deleted. The 12th save saves a file with counter 11 and deletes file 1, and so on. So the maximum number of version backup files is really 10, although the counter could be for example currently 35 and the version backups 25-34 exist.
But if you now close the file (or UltraEdit) and open the file again, UltraEdit will start again with counter value 0. After 10 saves you have version backup 0-9 and 25-34 from the previous session, and maybe other version backups from other sessions.
Well, I personally don't use version backups. I just looked into it today.
Do you think the auto-increase by 1 even with a maximum number specified is a bug or better not a good design? I also think so. Please report it by email to IDM support.
I expect and maybe you too that the version backup counter with a specified maximum number should be always smaller than the maximum number.
On first save UltraEdit should scan the directory for existing version backups for the current file according to the format specification, sort the files found according to the newest file date/time and use the number in the filename of the newest version backup + 1 as initial start value.
If no version backup for the current file with the format specified exists, the initial counter value is 0. It should be also 0 if the number of the newest file + 1 is greater or equal than the maximum number, if a maximum number of backups is specified.
And 2nd if a maximum number is specified, the counter should reset to 0 when the counter has reached the maximum number.
3 examples how I expect and maybe you too the version backup should work.
Example 1: Format: $n$c$e | Maximum Number: -1 (no limit) | Current file: Test.txt | no version backup exists.
1st save: Test0.txt
2nd save: Test1.txt
:
15th save: Test14.txt
File Test.txt is close.
File Test.txt is opened again.
1st save: Test0.txt
2nd save: Test1.txt
File Test.txt is close.
Example 2: Format: $n$c$e | Maximum Number: 10 | Current file: MaxTest.txt | no version backup exists.
1st save: No version backup exists, so save it as MaxTest0.txt
2nd save: MaxTest1.txt
:
10th save: MaxTest9.txt
11th save: MaxTest0.txt
12th save: MaxTest1.txt
File MaxTest.txt is close.
File MaxTest.txt is opened again.
1st save: UE has to search for files $n[0-9]+$e. It finds the files MaxTest0.txt, MaxTest1.txt, ... MaxTest9.txt. MaxTest1.txt is the newest one. So the counter value for next save is 2 and the version backup now created is MaxTest2.txt.
2nd save: MaxTest3.txt
:
5th save: MaxTest6.txt
File MaxTest.txt is close.
Example 3: Format: $n$c$e | Maximum Number: 10 | Current file: Test.txt | Version backups 0-14 exist from example 1.
1st save: UE has to search for files $n[0-9]+$e. It finds the files Test0.txt, Test1.txt, ... Test14.txt. Test14.txt is the newest one, but the value 14+1 is too high. So the counter value for next save is 0. The version backup now created is Test0.txt.
2nd save: Test1.txt
:
15th save: Test4.txt
File Test.txt is close.
The version backups 10-14 still exist from example 1. The user must delete them manually.
Second you might think the counter in the filename is 0-9 when you set it to a maximum number of 10. But this is not true.
When you open a file, UltraEdit sets the version backup counter for this file always to 0. On every save the counter is increased by 1. After 10 saves you have file 0-9. On 11th save the counter in the filename for next version backup is 10 and additionally the file with the counter 0 in the filename is deleted. The 12th save saves a file with counter 11 and deletes file 1, and so on. So the maximum number of version backup files is really 10, although the counter could be for example currently 35 and the version backups 25-34 exist.
But if you now close the file (or UltraEdit) and open the file again, UltraEdit will start again with counter value 0. After 10 saves you have version backup 0-9 and 25-34 from the previous session, and maybe other version backups from other sessions.
Well, I personally don't use version backups. I just looked into it today.
Do you think the auto-increase by 1 even with a maximum number specified is a bug or better not a good design? I also think so. Please report it by email to IDM support.
I expect and maybe you too that the version backup counter with a specified maximum number should be always smaller than the maximum number.
On first save UltraEdit should scan the directory for existing version backups for the current file according to the format specification, sort the files found according to the newest file date/time and use the number in the filename of the newest version backup + 1 as initial start value.
If no version backup for the current file with the format specified exists, the initial counter value is 0. It should be also 0 if the number of the newest file + 1 is greater or equal than the maximum number, if a maximum number of backups is specified.
And 2nd if a maximum number is specified, the counter should reset to 0 when the counter has reached the maximum number.
3 examples how I expect and maybe you too the version backup should work.
Example 1: Format: $n$c$e | Maximum Number: -1 (no limit) | Current file: Test.txt | no version backup exists.
1st save: Test0.txt
2nd save: Test1.txt
:
15th save: Test14.txt
File Test.txt is close.
File Test.txt is opened again.
1st save: Test0.txt
2nd save: Test1.txt
File Test.txt is close.
Example 2: Format: $n$c$e | Maximum Number: 10 | Current file: MaxTest.txt | no version backup exists.
1st save: No version backup exists, so save it as MaxTest0.txt
2nd save: MaxTest1.txt
:
10th save: MaxTest9.txt
11th save: MaxTest0.txt
12th save: MaxTest1.txt
File MaxTest.txt is close.
File MaxTest.txt is opened again.
1st save: UE has to search for files $n[0-9]+$e. It finds the files MaxTest0.txt, MaxTest1.txt, ... MaxTest9.txt. MaxTest1.txt is the newest one. So the counter value for next save is 2 and the version backup now created is MaxTest2.txt.
2nd save: MaxTest3.txt
:
5th save: MaxTest6.txt
File MaxTest.txt is close.
Example 3: Format: $n$c$e | Maximum Number: 10 | Current file: Test.txt | Version backups 0-14 exist from example 1.
1st save: UE has to search for files $n[0-9]+$e. It finds the files Test0.txt, Test1.txt, ... Test14.txt. Test14.txt is the newest one, but the value 14+1 is too high. So the counter value for next save is 0. The version backup now created is Test0.txt.
2nd save: Test1.txt
:
15th save: Test4.txt
File Test.txt is close.
The version backups 10-14 still exist from example 1. The user must delete them manually.
Best regards from an UC/UE/UES for Windows user from Austria
It seems the design could be improved. First of all, I looked back and I have files 1-199 for a single file. So I wonder if it may not be doing what we expect.
Secondly, I feel the counter system is a little strange. When I think of backup limited to 10 backups the maximum numbered backups should be 10. I read this as backup files will be named 0-9 (or 1-10) but never go over 10. What I expect to happen is the lowest number backup (file.1) should be the newest backup, and all old backups should be moved up an increment backup value. When a file moves beyond a value of 10, it should be dumped.
Secondly, I feel the counter system is a little strange. When I think of backup limited to 10 backups the maximum numbered backups should be 10. I read this as backup files will be named 0-9 (or 1-10) but never go over 10. What I expect to happen is the lowest number backup (file.1) should be the newest backup, and all old backups should be moved up an increment backup value. When a file moves beyond a value of 10, it should be dumped.
I may be late to reply, but it's not just you. I have my Maximum Number of Backups set to 10, yet I always see many more than 10 backups created for every file saved at least that many times. Obviously, if Maximum Number of Backups is set to 10, and UltraEdit creates an indefinitely large number of backups instead, something is wrong. And as a result, this feature does not work entirely as mofi states.sfennell wrote:Is it me, or is Maximum Number of Backups not respected? In configuration under file handling -> backup I have Version Backup set to On Save with Maximum Number of Backups at 10. As I save my backup files far exceed 10 versions. Am I just using it wrong? or making wrong assumptions about how it should work?
To repeat, I'm not getting hung up on seeing backup files created with $c values greater than 10; I am pointing out that I've specified a Maximum Number of Backups of 10, yet still have an indefinite number of backups created for every file.
I'm stuck with version 12.10 because of another (unrelated) bug, but I don't see this issue addressed since anyway.
I just wrote here what I have seen and how I think the version backup should work. However, I don't use version backup and so I don't have reported this issue by email to IDM support. If sfennell or any other user also have not reported it by email, then IDM does not know about this issue and so it can't be fixed. Send a bug report email to IDM support. The more users complain by email about not correct working version backup, the higher will be the priority for fixing it in the IDM bug tracking database.
Best regards from an UC/UE/UES for Windows user from Austria
If I may add a comment: the backup directory setting doesn't apply to the "numbered" backups. I don't see why.
I only lookup these backups after some kind of an "oops"; in the meantime, I don't like my working directory polluted.
My 3 cents.
I only lookup these backups after some kind of an "oops"; in the meantime, I don't like my working directory polluted.
My 3 cents.
You have to add the path to your backup directory to the format string.vhdluser wrote:If I may add a comment: the backup directory setting doesn't apply to the "numbered" backups.
This is what I use: $b$n$c$e (press the ? beside the format to see what the different things $ means, $b is for your default backup directory)
