AutoRecovery bug in UE 18 (confirmed)

[Stilez]

I often end up with unsaved files in use, but AutoRecovery is doing odd things with them.
Example screenshot below UE before a crash, on restart, and when recovered.

UltraEdit recovery.png (76.73 KiB) Viewed 2284 times

Not all files restore; those that do have multiple files with the same path.
(Win7, files created the usual way, no scripts in use)

Has anyone seen this? Suggested fixes?


Update 10 Sep
Bug and reproduction confirmed by IDM, hopefully a bugfix will arrive soon.
Haven't checked whether earlier versions affected, they might be.

Bug effect: files and locations initially mis-reported; new unsaved files begin to duplicate existing names; in some cases AutoRecover can end up "losing" some existing files and deleting their .RAC files, and won't show or recover them on session start (though they may exist on disk).

[Stilez]

A second run gave this equally odd recovery:

UltraEdit recovery 2.png (24.82 KiB) Viewed 2282 times

I deleted all temp files, closed and restarted UE, opened 3 new files (Ctrl-N), typed something in them, waited, then simulated a crash/restart.
The three files are recovered but some shown in one place, some in another - and two are shown as being in the System folder.

[Mofi]

That's very strange as files opened with using a temporary file are usually always created and updated in the folder defined by environment variable TEMP.

I suggest to first restart Windows to make sure that a security update being possibly scheduled for being applied on next Windows reboot is finished. After Windows restart enter into address bar of Windows Explorer %TEMP% and hit key RETURN to open this folder. Delete all files and subfolders in this directory by pressing Ctrl+A and Shift+Del. It can be that some files or subfolders can't be deleted because processes started already during Windows boot have those temporary files open. Skip those files and subfolders, but delete all other.

Do the same clean up for the system temp folder %SystemRoot%\Temp used by applications started with SYSTEM account instead of user account. In Windows Start menu under Accessories - System Tools there is a Disk Clean Up utility which can be also used to clean up files in temporary folder and other files secure for deletion.

The environment variable TEMP is hopefully set to a directory where you have full control with your account. Verify that by making the clean up as described above.

Verify also if uedit32.ini does not contain under [Settings] the special entry Temp File Dir= for using explicitly a different directory for temporary files.

Also verify that on drive with directory for temporary files (often drive C:) there is enough free space (about 10% of partition size). I have seen users which wondered why programs are not working as expected because the drive was already full. And defragment the drive if never done.

Last, UltraEdit saves auto recovery information in a folder named autorec with hidden attribute. The folder is located in same directory as the used UltraEdit INI file. Open Advanced - Configuration - Application Layout - Advanced to see the INI file location. Usually the directory with the INI file is %APPDATA%\IDMComp\UltraEdit and therefore this directory contains the hidden subdirectory autorec. In this hidden directory there is at least one more directory with name name of computer@user account name. In this directory UltraEdit creates the *.rac files containing the information for auto recovery after a crash. Verify that this directory exist and you have with your account full control in this directory by creating in this directory a file, write something, save the file and delete the file. Of course your computer name should not contain any character which is not allowed in a directory name.

[Stilez]

Thanks - quick checks show:

Path includes UltraEdit's program folder. TEMP is valid and I have full R/W/D control over the folder. The folder it points to contains temporary files of my text files. I don't have access to the Windows\Temp except via elevated access, which shows neither it nor \system32 have any UltraEdit edit*.* files. Users\NAME\AppData\Roaming\IDMComp\UltraEdit\uedit32.ini doesn't contain the setting you give (jumps from "Te1Converted=" to "Template Auto Suggestions="). C: has 4 gb spare.

There is an Autorec\comp@user folder at both Roaming\IDMComp\UltraEdit\autorec and Roaming\UltraEdit\autorec. both have R/W/D access and there are .rac files in the former. The .rac files are binary but contain a plain text filename, presumably of the file that they refer to. What I do notice is there are 3 .rac files and 3 edit*.* files, but the filenames embedded in the three .rac files don't all match the filenames of the three edit*.* files. Also the screenshots show UltraEdit reporting 2 different files having an the same path, and files in folders they aren't in, which should never happen whatever else is going on, and looks like a mis-reporting issue?

[Mofi]

Path includes UltraEdit's program folder.

That is not important. I use UltraEdit since many years without being in PATH. Adding program files folder of UltraEdit to PATH makes only sense when starting UltraEdit from command line by just entering uedit32. As I do that never, I selected on custom installation not adding UltraEdit program files folder to PATH.

... uedit32.ini doesn't contain the setting you give (jumps from "Te1Converted=" to "Template Auto Suggestions=").

The entries in uedit32.ini are not sorted, you would have to run a Find for the setting. However, I don't think that you added Temp File Dir= manually which is the only method to set a different folder for temporary files as this setting can't be added or changed within UltraEdit anywhere.

A *.rac file is created when an opened file is first time modified and deleted immediately when modified file is saved or closed without saving the changes. On my computer the *.rac files contain always correct file information. The *.rac file contains just the full file name of the temporary file for a modified new file not yet saved with a name. The *.rac file contains the full file name of the temporary file and the full name of the original file for a modified file with a name. *.rac files are not created for files opened without usage of a temporary file as every modification is done immediately on original file.

So if you can see that the *.rac files contain the full file name(s) not correct, there is something wrong on your computer. What's wrong cannot be analyzed by me and I don't have any idea to find out the reason for this behavior. I can only suggest to make the standard tests like checking the drive using chkdsk command of Windows, or test hardware, especially the RAM of the computer. You may use free tool Process Monitor from Sysinternals (Microsoft) with just file system activity monitoring enabled and look what's going on when you edit files in UltraEdit.

[Stilez]

Ultraedit recovers 3 different files in this screenshot but reported the same path for 2 of them. That alone says it's a bug, because there is nothing the OS can be doing to tell it this. (If the path was the one the files were really at, then it would not restore 3 different documents.)

Ultraedit also reported files to be in the system folder but when "OK" was clicked restored a version was clearly pulled from disk but not from the path it had stated. That also says it's an UltraEdit bug (same reason, if the path reported was the one it recovered from then it would have not been able to recover a draft as the path reported did not exist).

Chkdsk, hw and other programs are all checked and normal. Tracking file system activity is sensible, I'll do that when I can to see if it shed light. But the bug is clear. It might be a bug in the paths reported for files in the autorecover dialog and open documents panel?

[Mofi]

Well, if there is a bug in UE v18.10.0.1018, I'm unable to reproduce it on my computer. If you can reproduce the issue on your computer, I suggest to report the problem to IDM support by email with the step by step instructions how to reproduce the problem.

[Stilez]

The bug's a bit more severe than just "file names look odd", there's a bug in recovery causing data loss, not just path/name display. Reported to IDM with step by step reproduction method, good suggestion Reply received "I am able to reproduce most of what you reported. I will ask our developers to look further into this." Knowing the dev crew I think a speedy fix may turn up.

[Stilez]

I am disappointed, as the communication so far has been 1) idm's confirming bug is reproducible, 2) ?

[mwb1100]

I am disappointed, as the communication so far has been 1) idm's confirming bug is reproducible, 2) ?

3) profit!

(sorry - I couldn't help myself...)

[Mofi]

4) Priority of bug depending on number of users reported it.
5) Importance with regard to restriction on usage of UltraEdit for the daily work with text files by UE users.

The number of users which reported this problem is most likely 1.

The importance is very low as usually the auto recover feature is not needed by the users. Users close/exit UltraEdit usually normally and not kill uedit32.exe process via task manager. And a crash/hang of UltraEdit is also rare. Reproducible situations resulting in a crash or hang of UltraEdit are fixed usually very quickly because of their extremly high importance. And last most users work with named files and not lots of new, not yet saved files.

I have sent to IDM more than 500 problem reports and feature requests in the last 12 years. About 100 problems / feature requests are still not processed yet to my satisfaction. All of the not yet processed problems are of low priority even for my work with UltraEdit.

[Stilez]

I would disagree.

Data loss is almost always the highest priority. No matter what you do, if data is easily lost, it's more serious than any new feature or gimmick.

Systems (especially windows) are not stable, and bugs, hardware failure and other issues happen at a steady background rate. Autorecover is the sole protection against system corruption or any kind of crash. To say it is "not usually needed" is missing the point. It's there for the times it is needed - and it's badly buggy.

I find an attitude that data loss isn't important because "most users don't need it often" incomprehensible. Perhaps a fault in a car airbag, database system, or computer disk filing system that it can reproducibly fail or lose data "but not often, so let's ignore it" makes sense to you. It doesn't to me. Some things are relied on specifically for when a problem happens. It's expected to be rare. It's also expected to do its job.

[tsmith35]

I would disagree.
I find an attitude that data loss isn't important because "most users don't need it often" incomprehensible. Perhaps a fault in a car airbag, database system, or computer disk filing system that it can reproducibly fail or lose data "but not often, so let's ignore it" makes sense to you...

Recovery systems are used to help ensure that non-normal circumstances don't cause data loss. Such systems, often the last line of defense against data loss, must be functional and dependable. The seat belts and airbags in my cars are very, very rarely used, but when they're needed, they must work properly. The same goes for my backup systems: if I can't depend on them to safeguard my data, they may as well not exist.

The fact that UE rarely crashes is a testament to the stability of UE and the skill of its programmers, not a guarantee that UE will never crash. I think it's good that Stilez found this issue and reported it, something that the great majority of users would not do. Better to find a faulty recovery system issue before a crash than after.