Windows 7 Deletes my Programs

[buddyrich2]

I am a VFP9 user and recently upgrades to Windows 7. Everything worked fine for about 3-4 months (I was worried that it wouldn't work well under 64bit but it seemed to do fine).

All of a sudden, most every time I either try to compile or save a program, I get a 'file access is denied' error and my program (.prg) is deleted. To restore I have to change the suffix of by .bak file to .prg but none of my changes are saved.

I think this is a a Win 7 problem because this never happened before.

Anyone have any ideas?

 

[buddyrich2]

No, I'm not using any of the classes. Thanks.

 

[Dan Freeman]

OK, I've just verified that there's no problems using a directory of that name to create, modify, and save any file type in that directory.

Note that I *DON'T* get .bak files. That's a clue.

VFP makes the .bak files as part of saving, but deletes them when the save is complete. So something in your environment is preventing the save.

What's your network environment like? A domain? Are you an administrator user? Do you see different results if you run Foxpro as administrator? (Right click on it, run as administrator)

 

[Dan Freeman]

Note that in Vista and Win7, there is a marked difference between being an administrator, being a member of the administrator group, and running as administrator.

They sound the same, but they're three distinctly different conditions.

 

[buddyrich2]

I've tried running as an administrator and it still does not work.

Very interesting that you don't get .bak files. I have always gotten them... is this a setting in VFP?

I definately think this is a clue. Anther clue is that I end up with .TMP files (they contain the program when I open them). Something is trying to do a normal save and I end up with .TMP files because it does not work!

Wonder why.

 

[Dan Freeman]

So we're back to not answering the questions you're asked.

Is EVERY file being saved in c:\enrollment?
What's your network environment like? A domain?

I asked the first question because it can be darned difficult to tell what VFP is really doing when you work in the IDE. I asked the second one because a network-imposed policy setting that disallows writing to unapproved local locations could cause this problem.

I think you need to have a talk with your sys admins, but that's just an impression because you haven't answered.

The bottom line is that VFP, alone, has no problem saving files. Something is interfering with it. You have to figure out what that is.

 

[buddyrich2]

Its just a single computer sitting at home. No network. No sys admin - just me here.

 

[Dan Freeman]

That's one out of two.

I'm pretty much done for the evening. Hopefully someone will come along with better guessing skills.

To get them started:

* are you opening the files from the project manager?
* from Windows Explorer?
* from the VFP menu?
* Just before save, what is VFP's working directory?

For future reference, that's FOUR more questions.

(The machine I'm typing this on is a standalone Win7 machine, no network, AV is running, and VFP saves files just fine.)

 

[buddyrich2]

To get them started:
* are you opening the files from the project manager?
No, just from the VFP menu

* from Windows Explorer?
I've tried this but there is no difference

* from the VFP menu?
Yes

* Just before save, what is VFP's working directory?
c:\enrollment

For future reference, that's FOUR more questions.
Thanks Dan.

 

[Olaf Doschke]

buddy,

you're starting to help. Why were you so stubborn before? You were only repeating your problem, but not answering questions.

I now know you're using McAffee, although Doug Hennig had thrown antivirus in as your second answer! Why did it take you so long to react to that?

I know someone else using McAffee, who does not having that problem, but it may be due to excluding directories or file extensions. That's an option you should test.

VFP makes the .bak files as part of saving, but deletes them when the save is complete. So something in your environment is preventing the save.

That's untrue, you have an option to do and keep .bak files when saving prgs, but that doesn't prevent overwriting the prg files with the new version. Indeed it can be assumed vfp does rename the old .prg to .bak and then saves a new .prg

Very interesting that you don't get .bak files. I have always gotten them... is this a setting in VFP?

Yes it's a setting. Tools->Options->IDE Tab->Specify file/Window Type: Program Files, then in Save Options check "make backup". Unchecking this will ilkely only make the problem worse, in that the new prg will not be saved and the old prg may be removed. So if you try to change that option, try with some new dummy prg just for testing purposes.

I'd still second DougHennig (again mentioned: your second answer!) it may be antivirus being alarmed by files renamed and overwritten.

If that is the problem, it would be solvable by excluding C:\enrollment from live scanning. You can let mcaffee scan that directory in a full scan over night, but exclude it from live scanning, guard or how it's called in McAffee.

You might also exclude .prg and .bak file extensions.

The suspicion is, McAffee is deleting the prg or perhaps just scanning it and making vfp fail to finish writing it, so it finally is messed and not written, while McAffee doesn't find a virus.

The suspicion UAC is the source of your problem was clear of suspicion for me as you said from the beginning the problem just began after VFP worked correctly for several weeks. The reason therefore can only be UAC if you turned that on at that time, being aware of it or not.

The second reason now to not investigate along the UAC route is, that you have the problems with prgs you save to your own C:\enrollment folder.

The antivirus suspicion is getting more important.

Bye, Olaf.

 

[Olaf Doschke]

Oh, and onaother category of applications working on all files is a backup utility, especially a live backup backing up new files, if it detects them being written. Then there is the indexing of windows. And I'm sure there are more categories I miss right now.

As you know it's happening to your prgs, you could set up Process monitor to monitor a directory of prgs. Yes, that would be another program accessing those files, but it will merely watch over what processes work on the files besides vfp9.exe, so you'll like find out the exe, dll or whatever also works on the prg files then lost.

Bye, Olaf.

 

[Dan Freeman]

Yes it's a setting. Tools->Options->IDE Tab->Specify file/Window Type: Program Files, then in Save Options check "make backup". Unchecking this will ilkely only make the problem worse, in that the new prg will not be saved and the old prg may be removed. So if you try to change that option, try with some new dummy prg just for testing purposes.

That's an often-misunderstood "feature". It never really worked as people wanted it to work, or as documented. I see that they modified the help file to more closely reflect what it really does:

"For some file types, ..."

although they left out "sometimes". I tried to document it for some courseware when the feature first appeared but it was too inconsistent. That was too many years ago for me to remember details.

As you say, this situation with saving files just screams interference. Something is interfering with Windows file I/O. Live backup is a good place to look.

 

[Olaf Doschke]

Well, the option "make backup" is only available, if you choose the file type PRG, so this only works for PRGs, but for me it works everytime, not only sometimes.

Nevertheless if buddy really wants to find out, I'd opt for Process monitor now, to see what other process is acting on the prg or tmp or bak file while foxpro saves.

Bye, Olaf.