UltraEdit 64-Bit - file change indicator always triggers when tabbing away from UE (solved)

Khuri · Sep 29, 2015#12015-09-29T10:01+00:00

Hi everyone,

I have this weird problem that occurred since I installed the latest 64-bit version of UE, Version 22.20.0.25 (on Windows 7, 64 Bit). The "file change indicator" kicks in all the time, saying a recently saved file has been changed although the file was not changed by anything except the file saving of UE itself.

The scenario is as follows:
I have a network drive connected to a second Windows 7 64-bit machine, where I run a local web server for development. This configuration has not changed between the UE version upgrade.
I open mostly all the files from this network drive, and it's the only one I noticed the problems so far. Local files don't seem affected by the problem.

At first it only occurred to a couple of files right after installation, but after a restart it was only one single file (from a project I've been working on) that UE reported as changed every time I tabbed away from UE.
It only happened to that one file, in a specific folder. If I moved that file to another folder, the problem wasn't there, nor if I copied it elsewhere. Only in that one folder it caused the problem.
After a little back-and-forth with the IDM support, who could not recreate the problem, I've tried a few suggested options from IDM and finally eliminated the problem by simply deleting the file from the folder and then rewriting it (copy&paste).

Now I've opened a new project (using the UE project manager) and every single file from that project is affected by the problem (no matter the extension).
I open them through UE, edit them and save them. Then I switch from UE to another application (for example a web browser) and go back to UE, it reports the recently saved file as changed, and if I like to reload it.
The file itself is not changed at all (confirmed with UC and file timestamps). If I save several files at once and then switch the application, all of the files get reported as changed.

Did anyone else experienced this behavior yet?
Any advice/ideas?

Here's a short list of things that I tried before so far, about the first problem when it was the single file only:
- deleted every occurrence of the file from the Uedit64.ini (filename, as in last opened file, line markers, etc.)
- deleted temporary windows files
- did a full file system check on the network drive (Windows check disk)

But I'd also like to report this case back to IDM again, and as they first suggested include my UE configuration files.
But since there's a lot of sensitive data in the options folder (like file history, search&replace options, FTP accounts, etc.) I'd like to sanitize that first and I remember there's been a script or tutorial here on the forums before about that (I guess from Mofi) but I can't find it anywhere. If I could be pointed to that again, I'd appreciate it!

Mofi · Sep 30, 2015#22015-09-30T05:48+00:00

First, as far as I know UltraEdit keeps for every opened file the file information about file size, last modification time and the file attributes. If anything of those data changes for a file opened in UltraEdit, the file change detection is triggered if not disabled completely. You could verify with free tool Process Monitor from Sysinternals (Microsoft) to check what changes on file information when UltraEdit gets back focus.

In filter dialog of Process Monitor displayed automatically on start set Path ends with name of one file in project then Include and click on button Add before closing the dialog with button OK. In application window click on last 5 icons on right side of the toolbar to disable all Show ... options and click once more on the icon with the filing cabinet with the magnifying glass to enable Show File System Activity.

Now start UltraEdit, make a change on the file, save the file, switch to another application, switch back to UltraEdit and when file change detection message is displayed, switch to Process Monitor, stop logging by clicking on third icon in toolbar from left side, and look on recorded file access if you can see what changed. Especially look on file information data.

Second, there is at Advanced - Configuration - Toolbars / Menus - Miscellaneous the button Clear history. Closing active project and closing all opened files, opening configuration dialog, clicking on this button, closing configuration dialog with Cancel and exiting UltraEdit results in an INI file with no histories included anymore. Other settings like FTP account settings must be manually removed from a copy of uedit*.ini.

I can't remember having ever written a macro to remove private data from an INI file. I think, have written once what should be removed manually.

However, you could also rename directory UltraEdit in directory %APPDATA%\IDMComp for example to UltraEditBackup while UltraEdit is not running. Then start UltraEdit which recreates this directory with all configuration files created new including INI file with all settings set to default. Open your project and check if you still get a false message about a file change after making a modification, file save, switching to another application and back to UltraEdit. When even with standard configuration a false file change detection occurs, you don't need to send IDM support your configuration. Exit UltraEdit, deleted directory UltraEdit and rename UltraEditBackup back to UltraEdit.

Third, you could open Advanced - Configuration - File Handling - File Change Detection and select Disable for File Change Detection and uncheck Check files for changes only on application focus change. Disabling file change detection completely makes mainly sense for working on files on network drives to avoid network traffic and when knowing that the opened files are not changed by another application while viewed or edited in UltraEdit.

I suppose that there is really a bug in 64-bit version of UltraEdit which is responsible for the false file change detection messages. I hope, you are able to bring some light in the darkness about this bug and the developers of IDM find out the reason for this unwanted behavior with information provided by you. The Process Monitor log which can be also saved and sent by email to IDM support for investigation might be helpful. IDM support has also Process Monitor and can open the log stored in native format.

Khuri · Sep 30, 2015#32015-09-30T07:26+00:00

Thanks Mofi!

I've reset the config for UE and the problem persists.
Using the mentioned "Process Monitor" I played through the problem once and found that my local virus scanner is the only software that also accesses the file.

I've forwarded the logfile and those informations to IDM again, hopefully they'll be able to recreate it

I'll keep you updated, thanks!

rblandau · Jun 17, 2016#42016-06-17T21:28+00:00

You are not alone with this problem, I'm sorry to say. I have had it since I installed Windows 10 on my Windows 7 and 8.1 systems, which run UltraEdit-64. Editing files stored on a (Windows 7) file server causes this problem for me.

If I save a file being edited, then go to another application while UltraEdit still has the file open (but the file has been saved to disk), *some*thing touches the file, changes its modified/changed timestamps; and this causes UE to put up the "file changed; reload file?" dialog unnecessarily. Not fatal, but very irritating.

What process is changing the file dates (but not the file contents) behind my back? I have no idea, but it is something in Win10 and the way it interacts with the Win7 file server. At least, that's what it looks like to me at this point.

I have given some information about this to UE support, and I hope that they will find some way to make UE play better with Win10. Let's keep our fingers crossed.

rick

Mofi · Jun 18, 2016#52016-06-18T08:21+00:00

Rick, I suggest to

download free tool Process Monitor from Sysinternals (Microsoft),
extract the ZIP file for example to %ProgramFiles%\Sysinternals as administrator or any other local directory,
run Procmon.exe as administrator,
in displayed Process Monitor Filter dialog select Path ends with name of file opened in UltraEdit then Include, click on Add and on OK,
in the now opened Process Monitor main window uncheck the last 5 options in toolbar with the exception of the briefcase for showing file system activity.
Press Ctrl+X to clear the current record,
switch to UltraEdit, edit the opened file, save it, switch to other application, switch back to UltraEdit
and if the reload message prompt appears,
switch to Process Monitor, press Ctrl+E to stop capturing, and look on the log.

Has any application modified the file date or file attributes after UltraEdit saved it?

Khuri · Jun 18, 2016#62016-06-18T12:34+00:00

A little feedback on this on from my side.
I've had contact with IDM about it, but after a few trial and errors they've been unable to recreate the problem or find something in my logs, and I've turned off the file change detection since then.

I tried out it now, but the problem remains (with latest version of UE). As soon as I turned on the file change detection feature in the settings, the current opened file was detected as changed.
I've been working a bit with the detection on now, and it seems to pop up at random for files after being saved, that means it doesn't always happen.

Maybe you can find something with the method Mofi suggested.

rblandau · Jun 18, 2016#72016-06-18T17:57+00:00

Mofi, thanks for the suggestions. Yeah, I considered running the SysInternals process or file monitor, but I really think it must be something blatant and obvious. (And basically I'm lazy.) If UE support does not come up with something in a week or so, I'll do that.

rick

---------- (later)

Mofi, I did run procmon and make log files for UE to look at.

Odd problem: I could not run procmon on my normal Win10 system. I got the usual "Unable to extract x64 image...." message. Tried every suggestion I could find in stackoverflow and elsewhere, with no success. Then I ran it under the Cygwin on my system and it worked fine. There is something funny about the Win10 TEMP directories that is not easy to change (at least not by me), but Cygwin's /tmp works just fine.

rick

Jun 21, 2016#82016-06-21T20:07+00:00

After several round trips with UltraEdit support, I received the following great suggestion, which works for me. Let the forum know if it does or does not work for you, too.

Go to Advanced -> Settings -> File Handling -> Advanced and check Copy file instead of using rename when creating backup file.

Apparently something happens under the covers when UE creates a backup file, either .bak or file(n).ext, and that something is slightly different between Win7/Win8.1 and Win10. In my case, the file I was editing and the backup files were both on a network file server (also Win7), but on different logical volumes on that server. I'm not sure what the final straw was, but the combination was enough to provoke this behavior.

Now I can keep file change detection turned on for all the useful cases, and not be bothered by extraneous notifications. Works kewl.

Gold star to UE support (Ben) for persevering until we had a solution for this irritating glitch.

rick

Khuri · Jun 22, 2016#92016-06-22T13:02+00:00

Good finding!

I'm actually making backups as well, without the mentioned option set. Setup is similar, using Win7 64-Bit and saving to a network drive on another Win7 64-Bit machine.

I've changed the option you mentioned this morning and turned on file change detection again, and had no trouble throughout the day. Changed files twice by hand with other software while having them opened in UE, and those changes have been correctly detected, but no more "ghost changes".

Thanks for your feedback and for finding a solution! Send my regards to the UE team and Ben, I've had the pleasure to talk to him before as well

Please let them know that this option change fixed the problem for me as well.
I hope it helps them to expand their product even further or at least add it to their knowledge base for others who might stumble on this.

Mofi · Jun 22, 2016#102016-06-22T17:14+00:00

"Unable to extract x64 image ..." is an error which can occur if the directory of the executable is write-protected according to a post in Sysinternal's forum. This should not be the case on having Process Monitor extracted to %ProgramFiles%\Sysinternals and running it as administrator. But perhaps it is better to create a directory C:\Temp, extract Process Monitor into this directory and run it now as administrator. Also possible although not very likely is that there is no environment variable TEMP defined for local administrator account or the define temporary files directory is write-protected or contains too many files and subdirectories. I use the Sysinternals' tools only from a local directory with full control for all users and therefore don't no details about directory limitations.

However, more important is that there is now a workaround for this issue by changing a backup related setting in configuration of UltraEdit.

It is nevertheless very interesting for me as being a programmer why this issue did not occur with 32-bit UE according to first post by Khuri.

I tested with 32-bit UE v22.20.0.49 on Windows XP which modification of data in file information structure triggers the file change detection prompt.

Modifications ignored by UltraEdit:

a change of archive attribute,
a change of hidden attribute,
a change of system attribute,
a change of creation date,
a change of last access date,
a change of alternate (8.3) file name.

Modifications taken into account by UltraEdit:

a change of read-only attribute,
a change of last modification date,
a change of file size (and last modification date unchanged).

All other file data of low level FILE_ALL_INFORMATION structure not evaluated by me. Well, I see in Process Monitor log a buffer overflow on each QueryAllInformationFile operations. But according to Mark Russinovich's technical blog about Buffer Overflows this is okay if UltraEdit provided enough data memory to retrieve all information with the exception of the file name being the only variable structure element which is already known by UE. I suppose that UltraEdit uses GetFileInformationByHandle.

I will maybe in the future look on this issue again with 64-bit UltraEdit on Windows 7 with a network drive.

By the way: Khuri, Rick, do you mean with network drive a public share of a local directory on another computer (not a network-attached storage (NAS)) mapped to a drive letter or do you mean accessing files on a public share on another computer using UNC path?

(Retrieving file information from NAS systems is sometimes problematic as I know from my company like I copied a file into a directory on NAS which I can see in my file manager, but a colleague can't see it with his computer until I make one more change in the directory whereby with have both mapped the share on NAS to a drive letter. Our IT department finally found a solution for this issue, but I I don't know the solution.)

Khuri · Jun 22, 2016#112016-06-22T17:33+00:00

In my case it's a normal network share on a laptop mapped to a local drive letter. The laptop has a local webserver running. If I'm at my desktop, I simply work from there on the laptop files through the network share.

Since you mentioned too many files, my backup setting does create a rather long file history. Backup is made to the local hard drive when I work on (external) files on my desktop.
The format is: $b/$p/$n$e/$n($c)$e
Keeping up to 100 copies of a file.

It's not using the default Windows Temp folder, since the backup folder is also backed up incrementally periodically.
The backup folder basically mirrors the external directory with it, accumulating over 20.000 files throughout the years of using this method.
But they're all packed in their respective subdirectories as you can see from the backup format, so it's not just one folder with all the files in it.

Mofi · Jun 23, 2016#122016-06-23T05:10+00:00

Khuri, thanks for the details. I might investigate this issue sometime in the future and might try to reproduce the issue.

There is the limit of 65535 entries per directory. An entry is a name of a file or a subdirectory. As many applications don't remove temporary files and subdirectories in %TEMP% by bad design and not caused by an application crash, this directory can after months or years without a cleanup reach this limit. And then many applications using temporary files have a problem, see Cannot create/open new file for details.