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.

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).

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.

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?

Stilez wrote: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.

Stilez wrote:... 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.

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?

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.

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 wrote: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...)

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.

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.

Stilez wrote: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.

A couple or so months ago I reported that Autorecover was badly buggy in v18 and still badly buggy in v19. (Autorecover enumerated recovery files incorrectly, showed files in wrong folders, lost files when session crashed, etc). Autorecover is like an airbag - one hopes to rarely need it, but it matters that it works on the rare occasion.

In the last few weeks Troy has worked wonders in getting this taken seriously, and in v19.10 autorecovery is finally much better. There are only a couple of bug issues and he's confirmed those are in hand too. Remaining are -

• If a recovered session had unsaved newly authored files, AND the user after restoring and continuing the session opens a further new unsaved file (CTRL-N), autorecover only recovers one of the two files that were open. Fix - UE shouldn't essentially give 2 different working text files identical names/paths. Workaround - after autorecovery don't create new unsaved files until you've properly saved any existing unsaved files (once saved their folder won't be in the same location so it's fine)
• Config changes where the session later crashes, are silently lost, even if the user had clicked "apply" or "OK" and believes they are saved. Clicking apply/ok doesn't save config changes, and the failure isn't always obvious (Scenario - URL for files changed from branch A to branch B, if this is lost and the two have similar code, it might not be obvious the wrong files are being loaded in subsequent sessions. Ditto regex changes, backup criteria, etc). Easiest workaround - exit UE after making important config changes to ensure they're saved.

(I did tie Autorecover up in knots in a third test but it isn't clear if fixing these will fix that too)

I still think that the auto recovery bug under certain conditions is not really important for 99.9999% of the UltraEdit users. More important is that UltraEdit does not crash because of an error in source code.

I want to add my opinion on config changes where the session later crashes, are silently lost.

There are in general 3 different methods for handling configuration settings:

1. Settings are loaded on startup and saved whenever a setting is changed. This method is mainly used by applications saving settings in Windows registry as the registry is permanently loaded in RAM and saved regularly by Windows. Applications saving configuration settings in a file usually don't use this method, except the application is badly coded.
2. Settings are loaded on startup and saved when the user changes them in one or more configuration dialogs. This method is used mainly by applications saving the configuration in 1 or more files and not in Windows registry and which do not contain configuration settings which can be modified anywhere else within the application like in context menus.
3. Settings are loaded on startup and saved only on exit. This is a very efficient method for applications having configurations which can be modified by the user also outside a configuration dialog. Such applications need to handle often also settings changed dynamically by the user by simply clicking on an icon, a context menu or a button, and lots of history entries. And very often such applications support multiple instances where special handling for the configuration file is needed to avoid that two or even more instances read/write simultaneously the settings from the configuration file(s).

I'm also a developer for Windows applications and I use always third method although I know that when a user makes changes in configuration and then the application crashes, the changes are lost as all other modifications on the settings made outside the configuration dialogs. But I have designed my applications NOT to crash. So this case is simply unimportant.

Everything can happen up to a not starting computer when the entire PC crashes. I have once repaired a Windows machine which crashed and where next start failed as 1 bit in 12th byte of Windows system registry file was wrong as I later found out after repairing the registry file by using a Bart PE CD and systen repair snapshot of the system registry. I'm a developer for protective devices for power plants, substations and transformers with 20 years of experience in this area including IEC 61508 and design of hardware and software granting SIL3 (safety integrity level 3). All engineers really knowing what safety integrity level means know that a personal computer cannot be made safe. The software running on PCs is always unsafe and every PC hardware failure can always result in an irreparable loss or corruption of data.

That does not mean that developers of software for personal computers should not think about strategies on recovering data after an unexpected events like an application or total system crash. But the management of the software company has to decide how much time and money is invested in thinking and implementing of detection of corrupt data (often easy, but not for text files) and data recovery (extremly difficult) as PCs are unsafe by design.

By the way:

Apply means: Take over the values of the settings in ALL the configuration dialogs (not just the one currently displayed) and apply them to the application, but keep the window (configuration dialog) open.
OK means: Take over the values of the settings in ALL the configuration dialogs (not just the one currently displayed), apply them to the application and close the window (configuration dialog).

As Microsoft designed for Windows the 3 main buttons for property sheets as used for configurations, it was no accident that those buttons were labled OK, Cancel and Apply and not Save, Cancel and Apply. It is a common mistake that users think that OK means Save. Only a Save button should really result always in an immediate saving of the data. A button labeled OK just means okay for the entered data, and nothing more.