Windows 7: File save error...

This has been puzzling me since Vista and now Windows 7; at least now I know the reason...

The type of file being changed is .txt, .css, .html, etc. Open the file in Notepad, Dreamweaver, or any other HTML editor, modify the content, and save or "Ctrl+S" the file under the original name. Windows does not allow saving the file and presents this pop up:



Reducing the content of the file generally does not result in this error, depending on the level of reduction; addition on the other hand always does.

The culprit for this error is the Windows Explorer layout, more accurately the "Preview pane" under "Organize\Layout" section. Explorer displays the content of the file in the "Preview pane" if and when the file name is highlighted. As far as Windows is concerned at that point, the file is "opened/owned" by Windows Explorer and as such, the system locks file editing by any other application. It doesn't matter that both the Windows Explorer and the file in itself opened by the same user, evidently Windows Explorer process takes precedent over other application process when it comes to modifying file content. This file lock is temporary and last until the file name is highlighted or Explorer is closed. The permanent fix for this error is to disable Explorer's "Preview pane", especially for people who edit HTML files with Notepad or any other HTML editor.



Interestingly, none of the MS Office files display this error when editing word, excel, etc, files. Microsoft did make provision for the Office files; however, it isn't only Notepad that hasn't been accounted for. For example Microsoft Expression Web 3 also falls victim to this error:



The "Preview pane" is most certainly a feature that should behave the same across the board instead of being dependent on the file extension. Does anyone have an idea how to make Windows handle any file extension the same way as it handles Microsoft Office extensions?
TIA...

Cr00zng

Try closing the Explorer window prior to save the file, or change it's view to a different directory prior to saving the file.

That just hides the issue and it still results in additional steps to save the file. Disabling the "Preview pane" also hides the issue; however, no additional steps required for saving the file.
I was looking for having the "Preview pane" and eliminate the extra steps for saving the file.

Might I suggest that something else other than Explorer is the culprit? I've just run a test to try an duplicate the messages you get. I create a TXT document, and populate it with as much data as I can (file sizes in the test ranged from a few KB to several MB). I highlight the file in Explorer so that it shows in the Preview Pane. Then I double click to open in Notepad and make some changes. Before saving, I go back to Explorer to make sure that the file is still highlighted and visible in the preview pane. When I go back to Notepad and either CTRL+S or FILE->SAVE, in all instances of the test, the file saved correctly, with no ownership or in use warnings popping up.

I am not certain what else could cause this, seemingly on my and not your machine. I've reran the test as you described it and have the same result, no problems saving the file.

I've also retested editing my websites and have no issues with saving the files highlighted with Notepad, Dreamweaver, or MS Expression. This is weird, earlier the issue has been so evident; the posted images are proof that Explorer (or something else) did have the issue. The machine had not been rebooted and for that matter all the applications tested were and still are open.

I do recall that I've seen this issue a number of times before on occasions, both Vista and Seven; however, I had not been curious enough to find the reason until today. Maybe my conclusion has been wrong...

First off, I understand this is an old forum topic. But, this is the closest topic I could locate with the same issue as I am facing. Forgive me.

I just wanted to see if there was any further knowledge into this. Because what I am seeing is a bit more drastic. Not only does it not allow me to save the changes to the file, the file disappears all together after the issue is encountered.

Scenario:

1) Open html file in dreamweaver. Note: File showing in the preview window.
2) Edit the file.
3) Receive error upon trying to save the changes.
Error: "access to c:\users\<my pc>\desktop\BLAHBLAH.tmp was denied"
4) Attempt to close the application prompts me if I would like to save the changes. Knowing it won't save, I hit "No".
5) File disappears!!!!!

When I say disappears, I mean ... poof. Gone. The file is completely removed from the folder I had it in. Like it never existed. Not located in the recycle bin. Not anywhere. I've had this happen a few times, and it scares the crap out of me that files can be permanently deleted in such a fashion. Makes me wonder how many files I've lost because of this.

It's very weird. I mean, it makes sense to me that Windows explorer may think the file is being used via "Preview pane", yadda yadda. But, perm delete the file!?

Anyone else experience this?
If so, any recommendations? (lieu of disabling the preview pane, which I've already done)

Any help would be greatly appreciated.
Thanks!

-Jerry.

Just a thought, does this still happen if you run dreamweaver as administrator (right click on the program - run as admin)?

Suspect a permissions issue. Log in using the windows hidden administrator account, then try saving.


1. log in using your normal account
2. run CMD as admin.
3. type "net user administrator /active:yes" and hit enter
4.log off your user account. when the logon screen appears you should now see a new admin logon.
5.Login into this new admin and try alteing your files.
6.Before logging off this admin account go back to the cmd prompt and
type "net user administrator /active:no"
7.log off and re-login into your normal account.

I've had this issue. The only workaround I could come up with was to restart the PC and save the file after restart. Glad I'm not the only one seeing this issue.

Yes. This was my first thought and have previously tried this.
Even when I run under Admin, the issue is still present.

Oddly enough, I was NOT able to reproduce the issue logged in under the administrator account. So, you are undoubtedly correct. This is a permissions issue.

Any ideas?