File Permission Error (8) when trying to delete file

[DonRoth]

I am trying to programmatically delete (using the delete fx) a config(.ini) file that was originally created using the Open/Create/Replace fx. The file directory path is correct and the file is closed prior to the delete operation. I get a file permission error (8) when attempting the delete operation. I even tried adjusting the file access rights for full to see if that would make a difference but it did not. I am at this point not able to identify why I am getting this error, but I suspect it is something obvious. Your thoughts are appreciated.

Thanks,

Don

[BJD1613]

Don,

could you post the code so we could have a look at it?

thanks
Brandon

[DonRoth]

The code is a subsection to source code of over 100 mb llb for our ultrasonic scanner. I am trying to figure out a creative way to form a simple version of the problem but whenever I craft a basic VI utilizing the delete fx, the delete operation works just fine So as of yet I am not able to reproduce the problem in a simple VI. That is why I thought some folks could shed light or suggest some things to look for.

As I indicated in the initial post, I thought the origin of the problem could only be three possibilities: 1) the file is of the wrong name and therefore not found (although would probably get file not found error) but in fact it is the correct file and path, 2) the file is still open (it is not, I close it right before the delete fx), or 3)so
mehow some permissions have been set that do not allow a delete operation.

[Ben]

Hi Don,

I believe I heard Jean-Pierre explain this as having to do with the file system and delays in the file actually being closed.

There are lots of things that cuase this delay while running in a Windows OS. This may be due to the fact that the file system does not know the file is closed yet.

I believe the final solution was to check for the error, if detected, delay and retry.

Ben



Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com

[Robert M]

Hello Don,

Are you opening multiple files? If so, this knowledge base may apply to your case.

If this doesn�t help, or if I�m not correctly understanding your issue, please post the software and versions you are using, the applicable portions of your code, and any other information that may help, and I�ll be happy to look further into it.

Have a nice day!

Robert M
Applications Engineer
National Instruments

[DonRoth]

Hi Ben:

Your reply makes sense so I tried a combination of your solution and something I found on NI website:

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/7a2ba0127ef8ab7b86256587004e35fb/$FILE/new%20new%20delete.vi

I attached the .llb I made based on this. I still have error 8 when running this within my code. When running standalone, it deletes the file fine. The only thing I can think of is that somewhere I have a stray reference to this .ini file that has not been closed. But to that end, I have checked every single place where I open the .ini file and I have a close .ini file at the end of any read or write operation to in fact make sure the file is closed.

So at this point, I am at a loss to
explain the behavior. I developed a workaround that involves overwriting the file later in the program rather than deleting and recreating. The overwrite operation works as it should with no errors.

Sincerely,

Don

[DonRoth]

Hello Robert:

See my latest reply to Ben which in fact refers to the URL you point to....

Thanks,

Don

[grivilla]

I�m having exactly the same problem. I�m running win XP and LV 7.0. I created a file in a DOS box, closed the DOS box and tried to delete it again using the delete.vi. The DELETE.vi ends with file permission error 8. After that, sometimes the attribute �R� (read only) was set apparently by DELETE.VI.

Do you know a solution? Thanks.

Alberto

[JensM]

Hello to all of you,

I experienced the same problem and found a possibly more severe background problem:
I copied a file (or open / read / close will do the same) and then deleted the source.
Everything worked as expected in the test VI but the same did not work within my application.

The cause was a completely different file operation (on a different file). In this case I checked whether another file was present by opening it and checking the error condition. If it was not found I got an error, if it existed I got no error and I closed the file.
The problem I got was that if the file was not existing Labview still was keeping a refnum on this not existing file. I missed to close this refnum. After closing it I also was able to close the first file.

My question now is: What if I would like to keep a second file refnum longer than the first one?
I guess from the programs behaviour that Labview is expecting the files to be closed in inverse order to their opening.
Is this true?
How should I plan larger software projects with several files and especially different tasks (rendezvous / notifier tasks) to be managed?

Best regards,

Jens Müller
ZIEGLER