How to debug/fix "File Already Exists" build error 2

[grahammiller]

Help! I'm trying to rebuild an application and late on in the process I get the message "File already exists" and the build fails.

This is a project I've built countless times in the past and I've never seen this problem before. A colleague of mine who also has Foxpro installed can build the same project without the error. I can't find any info on this enywhere - does anyone have a clue please?

I get the same error building using vfp7 and vfp9 (I have both installed) and I'm running on Windows7. I also get the same error rebuilding old versions of the project.

 

[Dan Freeman]

The first thing to do is figure out where it's stopping.

Open the debugger before you build. The Debug Output window will show each file being processed and show you where it stops.

 

[grahammiller]

Hi Dan

I didn't know you could debug the build process! How do you do this? I have the debugger open before starting the build, but nothing shows in the output window, or any other. When the error occurs there's no 'suspend' option to let you switch to the debugger either.

Is there some kind of build modifier I need to set to make this work? I can't find any options in the debugger or the tools->options dialog...

Regards

G

 

[Olaf Doschke]

There's nothing to it. It works as Dan advertises it:
Open the debugger, open the Window "Debug Output" (not Trace) and then go backto the IDE windows, Project Manager and Build.

There's no setting that influences this. I didn't know this earlier than in VFP9, so it might just be a VFP9 feature. If you tried with VFP7, retry with VFP9.

Bye, Olaf.

 

[foxup]

Hi Grahammiller,

It's a windows 7 thing. I've seen this before. It 'locks' the file so only a reboot will fix that.

Start by doing this.

Delete the .APP that it builds, reboot your computer and then re-compile the Build from beginning (build project, build app, build .exe). That will work (it works for me).

Let me know how it works out for you.


Thanks,
FOXUP!

 

[Mike Lewis]

Dan,

Thanks for the tip about the debug window (but why didn't you tell me about it ten years ago?).

Graham,

I'm not sure, but I think you need to actually select the debug output window before you start the build. Also, be aware that the last entry might force the window to scroll, pushing the other entries out of site. In that case, you will need to manually scroll back to see them.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

It's a windows 7 thing. I've seen this before. It 'locks' the file so only a reboot will fix that.

This sounds more like waiving chicken bones than scientific method.

A far more likely cause for that "lock" is an app stuck in its READ EVENTS so it doesn't exit until the PC is rebooted. It most certainly is NOT a "Windows 7 thing" or it would be far more widely reported.

 

[foxup]

Hi Dan,

You can call it what you will but I've experienced it with Win7-64 bit and it has nothing to do with READ EVENTS, INMO.


Thanks,
FOXUP

 

[TamarGranor]

I'll confirm that I have no trouble building an app multiple times in Windows 7.

Tamar

 

[foxup]

Hi Tamar,

As well as I but 1/100x I do get "File already exists" message during a build (as Graham does). It does happen very very rarely though.


Thanks,
FOXUP!

 

[Dan Freeman]

It takes long enough to reboot Windows I'd think you'd want to find the *actual* problem. <shrug>

 

[Mike Lewis]

I have to agree with Dan. Why wouldn't you want to solve the probem, rather than side-stepping it until the next time it pops up?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

If the message "file already exists" is about the exe, the only thing, in which Win7 or more precise UAC could play a role is, if your project is located in a protected folder and so the exe is not created in the project folder, but you would then notice in the first build already, as the exe then would not be created in the project folder, then.

The only reason any file can't be replaced is, if it's still opened. And one reason for an exe being opene for sure is, it's still running. Another reason can be a anti virus scanner monitoring the file being opened, intervening and thereby hindering VFP to do it's build job.

The solution obviously cannot be to exclude the exe file extension from scanning, as that would allow any program to do anything with any exe file, but you could exclude your project folders from scanning or exclude monitoring any vfp9.exe process.

Bye, Olaf.

 

[Koen Piller]

Hi,
Win7 rebuilding an exe can error when you place your exe in a protected directory.

Try to make the exe in a non-protected directory, like e.g. C:\MyExe
or better D:\myExe

where myExe is of course the name of your Executable.

And not in C:\Program Files(x86)\myExe

Regards,

Jockey(2)

 

[grahammiller]

Hi Folks

Thanks very much for all your input. I now have a solution, but not a very satisfactory explanation - but I can live with that!

Regarding debugging the build, Olaf's right - it doesn't work in VFP7.

I rebuilt in VFP9 and was able to see that the build was failing within the compilation of the FFC library '_movers' from the location C:\Program Files\Microsoft Visual FoxPro 7\Ffc. (FYI the 'date modified' date on this file is 2001...). I found another copy of this library on the network and used that instead and the problem was solved. Weird. I certainly haven't been messing with the foundation classes...

Please note (anticipating your comments...;-)):
1) The only reason I'm not upgrading to VFP9 for building this project exe generally is that it's massive and messy (an inherited system unfortunately) and I can't get the resource to test it.
2) I have no idea why the _movers foundation class is included in the project. It builds OK without it, but as per (1) I don't want to risk a release to production without testing.

Thanks again to all for your help on this.

Regards

Graham

 

[Olaf Doschke]

Open C:/Program Files/ and grant full access to the \Microsoft Visual FoxPro 7\ subfolder to yourself.

As FFC libraries are in the protected directory compiling of them is redirected into your user profile, and that's what I was already assuming.

See into
C:\Users\..yourusernamehere...\AppData\Local\VirtualStore\Program Files\Microsoft Visual FoxPro 7\Ffc

and you'll find the files compiled. One of them is blocking your build.

The best bet is to not install VFP into Program Files, but into eg C:\Public\VFP7

Or as initially said, grant yourself the rights to write in the program folder.

It's not new, that writing into program folder is disallowed. I'm sure you did grant rights to yourself in XP, and forgot about it. In XP you rather get the write permission denied error in the first place and no redirection into you VirtualStore, but it was not allowed to write into program files even in XP.

Bye, Olaf.

 

[Olaf Doschke]

Another solution: FFC classes come compiled, so you simply could set your build options to not Recompile All Files. Uncheck that and the compiler will only compile prgs with an outdated frx, vcxes with an outdated vct etc.

That also makes the build process faster.

Bye, Olaf.

 

[craigber]

I strongly suggest you do NOT do as Olaf says and grant additional rights to the VFP folder in Program Files as this basically throws away all the good that UAC does. Instead, copy the FFC classes out of the VFP folder into a folder that is not UAC protected, then change VFP settings to look for the stuff there.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Dan Freeman]

I'll agree with Craig here. The reason UAC exists is because *WE* were too lazy to do things the right way in the first place! Skirting it now is just adding to the problem.

 

[Olaf Doschke]

craig,

I partly agree. I think it's a calcualatable risc to add full access rights to this one program folder. You can officially choose a different install directory and then you have the same "insecurity".

Your recommendation would be nice, if it could work. Many FFC classes make use of HOME()+"... to refer to other ffc classes or files in the vfp folder, so moving FFC out of program files is just part of a solution, therefore.

If you can tell me how to define what HOME() returns as a folder, I'd be fine with that solution.

If not, then in an ideal world MS would change the VFP setup to put the non changing core VFP EXE etc into program files and put templates, tools etc needing write access in appdata or somewhere else suitable. VFP was not made with UAC in mind, even though we can assume the foxpro team could have known about such plans in the end of 2006, when Vista was near release already.

Besides I already said, there are other solutions, eg to compile without "Recompile All" option. You can also empty the VirtualStore/Program Files/Microsoft Visual Foxpro 7/ folder to be clean there and be able to recompile again.

Bye, Olaf.