UltraEdit 17.30.0.1002 will not show this subdirectory in the file explorer. Anyone else having this issue? (Need to edit the hosts file.)

See Read ini file in System32 problem Win7 x64 and the articles reference there with links.

There are some files specially protected with special permissions on Windows Vista and Windows 7 and newer versions of Windows so that they can't be easily seen, opened and edited. And the hosts file is one of these files.

Actually the subdirectory "etc" is not being shown, and thus the files in that directory are not available in UE File Explorer. Besides, I am administrator, running UE as administrator... I want God's access to my directories and files. I can see it in Notepad, Explorer, but not in UE File Explorer.... it's my file and I want it now.

Panchdara wrote:Actually the subdirectory "etc" is not being shown, ...

Yes, but that is not the fault of UltraEdit. Windows blocks UltraEdit to access this directory. Of course it must be possible with at least 1 application to access this directory and edit the files in this directory and therefore Microsoft has implemented in their Windows Explorer and their Notepad special code for accessing and editing files in this folder if certain conditions are true.

You can take ownership of this directory and then change the permissions so that all applications can access this directory and the files in this directory at least when the application is started in an administrator environment. But that opens the directory also for trojans and viruses.

You must understand that a special file and directory protection against access by malicious software results also in a protection against all other applications except specially trusted applications. And Microsoft trusts only in their own applications Explorer and Notepad.

Further it could be that your anti-virus guard blocks UltraEdit to access the directory and its files and let only Windows Explorer and Notepad access them.

Have you ever tried if opening hosts file with quick open of UltraEdit command works when entering the entire file path you already know?

On the other hand why not simply edit the file with Microsoft's Notepad?

PS: I'm using Windows XP SP3 x86 with an administrative account and don't have any problem to browse in Explorer tab of the File Tree View of UltraEdit to this directory and open the hosts file. This proves that not UltraEdit is responsible for not displaying this directory in the tree.

Yeah... on further investigation I see Special Permissions on this subdir... I understand the threat issues too. It would be nice to have been able to use UE File Explorer to directly access this file. Yes, I can right click on it and UE will open it, and yes if I run UE as admin and traverse to that subdir then I can open/edit/save it.

No worries, I know I can trust UE File Explorer only to a certain degree. (Perhaps a greyed out listing?)

Best

Thanks again. Oh, yes, I'm using Win7 dso is a little different from XP.

This problem has nothing to do with permissions. The c:\Windows\System32\drivers\etc directory is readable by anyone.

The problem has to do with UE being a 32-bit application running on a 64-bit system. In this case, the system performs a redirection of accesses to the C:\Windows\System32 directory to the C:\Windows\SysWow64 directory (unless the 32-bit application uses specific techniques to tell the system that it's 64-bit aware even if it's a 32-bit application). And there is no "etc" directory in C:\Windows\SysWOW64\drivers.

I'd consider this a bug - IDM should be informed that it needs to take those special actions to allow access to the non-redirected file system for opening files.

As an end-user, you can work around the problem by opening "c:\Windows\sysnative\drivers\etc\hosts" - sysnative is a 'special' name that tells the OS that you want to access the true System32 directory instead of being redirected to SysWOW64. However that name doesn't get enumerated by the filesystem, so you can't browse to it in the File Explorer window.

Panchdara has not written until now that he is using Windows 7 x64. But you can be right, if he uses really 64-bit version of Windows 7.

In my point of view this is not a bug. That Windows redirects 32-bit applications to the directories for 32-bit applications is not the fault of UltraEdit. Sure, IDM could use the method to access the directories for 64-bit applications by default, but what if the user wants to edit something in a directory for the 32-bit applications? So it would be necessary that File Explorer of UltraEdit does something which Windows Explorer does not, display always all directories on a 64-bit machine, those for the 32-bit and those for the 64-bit applications.

Mofi wrote:In my point of view this is not a bug. That Windows redirects 32-bit applications to the directories for 32-bit applications is not the fault of UltraEdit.

Yes, you are right that it's not the fault of UltraEdit, however the behavior that was new for 64-bit systems has been in place for more than 5 years - long enough for IDM to finally accommodate. 64-bit systems are no longer rarities, and I think that it's not too much to expect that the 32-bit UE behave optimally even on a 64-bit system. Since UE is the kind of application that a user will want to use to open and edit files in system directories, it should behave in a way that users expect it to on 64-bit systems. To do so, it needs to access the filesystem in a way that isn't confusing to users.  One way to get that better behavior is by offering a 64-bit version of UE, but I think just changing how files are opened (I forget the details at the moment, but I believe that it's more or less just passing in a particular flag when opening files) would be far less effort on IDM's part. I'm fine with calling this a 'feature enhancement' instead of a bug-fix.

My real point is that it's a problem for users and it should be addressed somehow by IDM. Note that I haven't said anything about the priority or severity of this problem (it's certainly not a show-stopper).

Mofi wrote:Sure, IDM could use the method to access the directories for 64-bit applications by default, but what if the user wants to edit something in a directory for the 32-bit applications? So it would be necessary that File Explorer of UltraEdit does something which Windows Explorer does not, display always all directories on a 64-bit machine, those for the 32-bit and those for the 64-bit applications.

I'm not sure I'm understand the potential problem you're describing - having a 32-bit application ask the system to not perform redirection doesn't restrict the user from 32-bit directories - it simply gets access to the file system as it really is. For a user navigating the file system to open a file for editing, that's preferable - particularly since things will match up with what they'll see in Windows Explorer.

The list of changes for hotfix version 17.30.0.1011 of UltraEdit contains the line

Explorer shows hidden/protected directories on 64-bit Vista/Win7

I don't have any computer running with Windows 7 x64 and so can't verify if the problem discussed here is solved by using this version of UltraEdit.

Could any UltraEdit user using Windows 7 x64 verify if directory C:\Windows\system32\drivers\etc is now also visible on the Explorer tab of the File Tree View and post here the result?

I don't have a UE license, but I do have a UE Mobile license. I tried UE Mobile 17.30.0.1016 on Win7 x64 and it does *not* see the C:\Windows\system32\drivers\etc folder in the File View window's Explorer tab.

Of course, it's possible that the fix is only in UE and not in UEm (either by design or accident).

I'm still waiting for UEStudio to get up to the same 'level' as UE 17.30.0.1011. It seems that UES is still at the .20 minor version level.

Just tried with UE Version 17.30.0.1014 and UE Beta 2 Version 18.00.0.1012 on a Win 7 Pro X64 system and neither of them display the /etc sub-directory in the Windows/system32/drivers directory. Only the /en-US and /UMDF sub-directories are displayed.

Cheers...

Frank

First, my apologies for not having been back to this thread for a while.

Yes the issue I initially wrote about is still an issue... and yes I am using Win7 64bit... Now that I am aware of that issue I can "get around" it.

Thanks so much for your valuable input.

Best
Hugh

To mwb1100: UES v11.20.0.1010 has the same editing core as UE v17.30.0.1016.

The release date is more important than the version number if comparing the features and fixes of UE with UES.

I raised this with IDM support in regard to the UE 18 Beta, and got the following reply from Troy:

Troy wrote:In order for the \etc folder to be displayed here, you have to add a setting to your %APPDATA%\IDMComp\UltraEditBeta\uedit32b.ini file under the "[Settings]" section:

DisableWow64FsRedirection=1

This resolves the issue described by "mvb1100" in the forum thread you referenced:

I've done this and can confirm that the hidden directories are now displayed.

So for a release version of UltraEdit, open %APPDATA%\IDMComp\UltraEdit\uedit32.ini with Notepad while UltraEdit is not running, run a Find for [Settings] and insert below a line with DisableWow64FsRedirection=1 to see the contents of directories for 64-bit applications.

Cheers...

Frank

Frank:

Thank you for that!

I can confirm that with the .ini file setting this works in:

• UE Portable 17.30.0.1016
• UEStudio 11.20.0.1010