Windows 10: Explorer cannot see a file but kompozer can !

I just created an html file with Kompozer and saved it to the C: drive root.

Then tried to upload it to the web but the file uploader browsing function from the host there didn't display the file.

So I looked with Explorer and it couldn't see it, either.

So I closed Kompozer and then opened it again and used it's 'open file' function to explore the C: root and see what was there. And there's the file.

How can Kompozer see the file? It is using exactly the same windows explorer function isn't it?

edit:

I just used the 'everything' search app and it found the files in AppData\local\Virtualstore and in \roaming\microsoft\windows\recent.

I don't understand.

How can explorer not see it? Actually there's two of them. I saved it again with different name.

I also first tried to save it to the inetpub folder and it reported it couldn't do that. So then I went the C: root and it apparently worked: but didn't?

further edit:

It seems to have something to do with not running Kompozer as administrator. Though I am logged on as admin the prog is not running under admin rights.

When I open it again and force it to run as admin Kompozer can no longer see the files. It now sees what Explorer usually sees and what is shown by the upload prog on my host.

So I guess I can maybe find this hidden folder and copy the files from there and put them in C: root - or perhaps even where they belong, in wwwroot - and box on, always running Kompozer as admin.

This is Win10 updates doing this. I've been using Kompozer on and off with win10 since inception and never run into this until today.

Appreciate any advice concerning this.

:)

 

File Explorer has gone crazy after last nights upgrade.

My only has icons instead of full descriptions. I can not get back to a point where I have tabs that actually say something. Please tell me how to get my view repaired? help... Help.... HELP!!!

 

File sharing with Mac OS High Sierra

My iMac can see the files on my Windows 10 PC, but the PC cannot see the iMac in file Explorer

 

Yes, I know. Got onto it and fixed it via some other route, don't remember what.

Actually the question is why can't Explorer see it? Meaning why did Microsoft, why did the programmers, choose not to let us see it?

And hence make it unavailable? When in truth it is available. Kompozer, for instance, avails itself of it and manipulates it.

Why should we be denied that functionality?

Let us see it and give an indication of what to do.

Much of this confusion on the part of the user arises because being Admin logon doesn't automatically mean all your progs are run as Admin - which you'd naively think they would be.

The quick fix for this which should be an automatic little popup hint window is to run the prog you're running as Admin - with reiteration of that surprising truth, that being logged on as admin doesn't mean it is being run that way.

Another fix which I think I've employed but I wouldn't swear to it because my memory is incredibly unreliable, is to change all permissions on these protected folders.

If my memory's not playing me false I think I got onto suggestions somewhere about doing it that way by adding 'everyone' with full access.

A bit of wild overkill you'd think perhaps, I know I did, but the hell with it I did it anyway.

Coincidentally just yesterday on a different machine (but still win10) I ran into the same problem with Notepad. At root the same problem. It didn't create a file in the virtualstore but I was denied the ability to write a file back to wwwroot after notepad had edited it!

So I finished up doing the same thing there: gave 'everyone' full permissions to wwwroot.

It's getting to be a habit.

A bad habit but what the hell. I'm not a lan manager in a public hospital any more, just a guy at home, I'll take the chance.

*Smile

 

Read up on virtualstore:

Please explain VirtualStore for non-experts - Microsoft Community

"To summarise, the hidden VirtualStore folder is part of the virtualization technology that was introduced in Windows Vista. This was intended as a compatibility feature to allow old programs to continue working when using User Account Control and running as a Standard User. It is surprising that you are encountering problems seven years later. This was a temporary fix intended to be removed in some later release of Windows.


For a program to be eligible for virtualization, it must be 32bit, not running with administrator rights and must not have been compiled with a manifest file indicating it is for Vista or later.
You can see the virtualization status of a program by adding the Virtualization column to the Processes page in Task Manager.
When a virtualized program attempts to write to a protected location such as Program Files, Windows will intercept the access denied response and redirect the write to C:\Users\<name>\AppData\Local\VirtualStore, which is a hidden folder.
When a virtualized program attempts to read from a protected location, Windows will first check for a copy of the file in VirtualStore. If it finds it, it will use that copy. Otherwise it will attempt to read from the original file.

"