0
votes

We are currently in the final throes of testing our existing application before we begin the process of migrating the company over to 32-bit Windows 7 with Office 2010. One of the remaining applications was written in VB6, and is experiencing a problem when it gets to perform a filecopy action.
Currently, it writes data to a file called MIDNSPTEMP.$$$ and when finished, uses the FileCopy command to copy it to an existing file called MIDNSP.$$$, where it gives me a Permission denied error. The next line which deletes the MIDNSPTEMP.$$$ is never hit.
If I create a new file in the same folder manually, that works, and I can also delete a file.
Can anyone point me at why it gives me a permission denied in this situation? VB6 is not a language that I am very familiar but no-one else is available to look at this.
Thanks in advance
Martin

2
Waht folder? I expect you're using a folder you don't have permissions to write to (The error message kinds gives that away :)Deanna
It's a network folder that I can write to and delete from, which is what threw me in the first place. I addd in a check to see if the files were closed properly, but it seems that they aren't closing which I'm guessing may be why I'm getting permission denied?Martin S
It could be, depends on your code that opens and closes them. Does your process still have them open? tcarvin's reply should help you tell. Until we see soem code, we can;t give a definite answer.Deanna
In simple terms, I have a FelxGrid control, and when a user double clicks on an entry, it opens the associated file in TextPad. Details are logged into a file, taking either the last line of the existing file or adding new details, and then the files are closed. Code to open the temporary file is Open Datadir + csNspTempFile For Output As #3, whereas the code to open the file being read is Open Datadir + csNspFile For Input As #2. Each file is then closed using Close #2 and Close #3 respectively.Martin S

2 Answers

1
votes

Windows 7 does not automatically run commands as an administrative user like it did in XP instead they are run with the least privlege. You will need to either grant less restrictive permissions to the folder where you are working or start the application as an administrator using run-as.

0
votes

Are you sure that the file is not locked by another process (or by another part of your own code)? ProcessMon ( http://technet.microsoft.com/en-us/sysinternals/bb896645 ) from SysInternals is your friend. It will record ever I/O to your file along with successes and failures.