Prev: The BIG Picture (VB vs the OS)
Next: Running VB6 app on W7 pro 64bit
From: Nobody on 25 Jan 2010 12:41
"jim evans" <jimsTAKEOUTnews2(a)houston.rr.com> wrote in message
news:7uhrl5ll9r8qtrbgvnb1791iej9h5f1u8l(a)4ax.com...
>I have a routine that opens a file for input, reads it, line by line,
> closes it and immediately Kills it. I am getting a Error 70,
> Permission Denied when Killing it.
>
> Any suggestions on what's causing this and what to do about it?

In which folder does that file resides? In the app's folder or temp folder
for example?

The error means the user doesn't have enough permission to delete the file.
Either you or the user's network administrator has to give that user
permissions. In some case, if the user is choosing which file to open, he
needs to make a copy to a location that he has write access to, such as My
Documents or the Temp folder. If it's something in the app's folder, you
need to relocate the file elsewhere to a location that is writable by the
user, such as under AppData. "Program Files" and sub folders are
Read/Execute only for members of the limited "Users" group.


From: Ralph on 25 Jan 2010 12:44
jim evans wrote:
> I have a routine that opens a file for input, reads it, line by line,
> closes it and immediately Kills it. I am getting a Error 70,
> Permission Denied when Killing it.
>
> Any suggestions on what's causing this and what to do about it?

The usual problem is a "timing issue". The Close method is merely signalling
to the O/S that the file can be closed, but it doesn't block until it is.

You can easily test for this by placing the "Kill Routine" in another
event - create a dummy button for example. If the file is killed by this
method, then go back an create a Timer. Something like ....
...
' current routine
Close fp
Timer1.Enabled = True
End <routine>

Private Sub Timer1_Timer()
Kill FileName
Timer1.Enabled = False
End Sub

If the Dummy Event/Button didn't work, then something else is going on. And
you will need to post more information.

-ralph


From: Patrice on 25 Jan 2010 13:00
Hello,

- the file is really closed ?
- it is not read only ?
- you are also allowed to delete this file and not only to read from this
file ?

Ultimately a tool such as ProcMon
(http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) should
allows to find out why the delete fails...

--
Patrice

"jim evans" <jimsTAKEOUTnews2(a)houston.rr.com> a �crit dans le message de
groupe de discussion : 7uhrl5ll9r8qtrbgvnb1791iej9h5f1u8l(a)4ax.com...
> I have a routine that opens a file for input, reads it, line by line,
> closes it and immediately Kills it. I am getting a Error 70,
> Permission Denied when Killing it.
>
> Any suggestions on what's causing this and what to do about it?


From: Nobody on 25 Jan 2010 21:19
"jim evans" <jimsTAKEOUTnews2(a)houston.rr.com> wrote in message
news:qdisl51c9h5k53qg7157fdbrjfp66f9j5a(a)4ax.com...
> This error is difficult to reproduce so it will take me a day or so to
> know if it's fixed.

Sounds like AV software scanning the file.


From: Ralph on 25 Jan 2010 23:45

"jim evans" <jimsTAKEOUTnews2(a)houston.rr.com> wrote in message
news:qdisl51c9h5k53qg7157fdbrjfp66f9j5a(a)4ax.com...
>
>
> On Mon, 25 Jan 2010 11:44:40 -0600, "Ralph"
> <nt_consulting64(a)yahoo.com> wrote:
>
> >jim evans wrote:
> >> I have a routine that opens a file for input, reads it, line by line,
> >> closes it and immediately Kills it. I am getting a Error 70,
> >> Permission Denied when Killing it.
> >>
> >> Any suggestions on what's causing this and what to do about it?
> >
> >The usual problem is a "timing issue". The Close method is merely
signalling
> >to the O/S that the file can be closed, but it doesn't block until it is.
>
> I think you're right about it being a timing problem. The odd thing
> about this is the error doesn't occur under most conditions. But,
> when I revise (open change and save) an entirely unrelated file before
> reading and killing this file, I get the error message. Other times,
> when I don't revise the unrelated file, the error doesn't occur.
>
> Rather that insert a persistent delay that will slow the program at
> all times, even when not needed, I am trying a solution where I trap
> the error, add a DoEvents and a Resume. I loop through this until
> the Kill does not produce an error or two seconds have elapsed.
>

You don't need to do a DoEvents(). DoEvents is for polling and clearing the
Application's msg/hdw queue. It works in this case because DoEvents also
calls Sleep(0), which surrenders your App's time slice to allow outside
processes (perhaps the AV as Nobody mentioned or the base I/O services) to
run.

Only running a 'loop' when it is needed rather than all the time is a good
idea. But you can accomplish the same using either a sleep or a timer. The
timer has the advantage of allowing your routine to 'continue' (Sleep
blocks) and thus appear more responsive.

But with any scenario you are also wise to provide an additional escape just
in case there is another issue. I would probably do this with a static count
in the Timer event.

-ralph


 | 
Pages: 1
Prev: The BIG Picture (VB vs the OS)
Next: Running VB6 app on W7 pro 64bit