Deleting Files

[Dimster]

I have a subroutine in a program which calculates a number of values. These are then stored to a file for future use. The program will return to this subroutine in the course of its run. The subsequent runs of this subroutine however is duplicating the values. I have tried to reset the local and dim shared variables used in the calculation to zero before the subsequent runs but still getting duplicate values. The values are being written to a file using "for output" which I thought would simply rewrite the corrected values (ie "for output" would in essence delete the old file) but that is not working.

I would now like to find another way to delete the complete file after the each run thru the subroutine but can't seem to find a command for this. I have tried Shell and Kill but it would appear I may not have Dos in my windows 10 os. In any event, is there a _DeleteFile command somewhere in the universe that may work in this situation? No big deal if there isn't as I don't know if that would solve my problem anyway. Thinking I need to scrap the whole routine and rework it - just the disappointment to see all those hours building the subroutine as a waste of time.

[Petr]

Check your paths if you really open the same file for writing (for example, if you don't have a file with the same name in the QB64 installation folder and the same in the program directory), I don't know of a single case where KILL or OPEN FOR OUTPUT wouldn't work. Standard for delete file is KILL "filepath+filename.extension"   To get current work directory use _CWD$.

[Pete]

If it isn't a path issue, my thought is, you cannot delete the file, because it is still open in the routine. Files need to be closed first. del can be used with SHELL, which works in Win10 via the command prompt.

http://www.easydos.com/del.html

But KILL will work in QB64, provided the file has been closed, first.

Maybe this isn't your problem, but I'm having difficulty understanding your explanation. If I experienced the routine, that probably wouldn't be an issue, but without a common form of reference, well, it leaves me just guessing.

Pete

[TempodiBasic]

Hi
reading the wiki http://www.qb64.org/wiki/OPEN#File_Access_Modes

OUTPUT: Sequential mode creates a new file or erases an existing file for new program output. Use WRITE # to write numerical or text data or PRINT # for text. OUTPUT clears files of all data and clears the receive buffer on other devices such as COM.

and this example of wiki works fine

Code: QB64: [Select]

1. CLS
2.  
3. OPEN "test.tst" FOR OUTPUT AS #1
4. PRINT #1, "If test.tst didn't exist:"
5. PRINT #1, "A new file was created named test.tst and then deleted."
6. PRINT #1, "If test.tst did exist:"
7. PRINT #1, "It was overwritten with this and deleted."
8. CLOSE #1
9.  
10. OPEN "test.tst" FOR INPUT AS #1
11. DO UNTIL EOF(1)
12.     INPUT #1, a$
13.     PRINT a$
14. LOOP
15. CLOSE #1
16.  
17. KILL "test.tst"
18.  
19. END
20.  

so playing with the code we can experiment that if you don't close OUTPUT file, you write data appending to the previous data as the following example shows

Code: QB64: [Select]

1. CLS
2.  
3. OPEN "test.tst" FOR OUTPUT AS #1
4. PRINT #1, "If test.tst didn't exist:"
5. PRINT #1, "A new file was created named test.tst and then deleted."
6. PRINT #1, "If test.tst did exist:"
7. PRINT #1, "It was overwritten with this and deleted."
8. COLOR 12, 4
9. GOSUB readfile
10.  
11. PRINT #1, "-If test.tst didn't exist:"
12. PRINT #1, "-A new file was created named test.tst and then deleted."
13. PRINT #1, "-If test.tst did exist:"
14. PRINT #1, "-It was overwritten with this and deleted."
15. COLOR 11, 1
16. GOSUB readfile
17. CLOSE #1
18.  
19. KILL "test.tst"
20. COLOR 7, 0
21. END
22.  
23. readfile:
24. OPEN "test.tst" FOR INPUT AS #2
25. DO UNTIL EOF(2)
26.     INPUT #2, a$
27.     PRINT a$
28. LOOP
29. CLOSE #2
30. RETURN

IMHO Petr and Pete have showed you where is the bug. :-)
Good Coding

[Dimster]

Thanks guys. The offending file was closed - still not sure why the Shell Kill is not working and will explore that but I think I may have discovered a possible cause. The program is complex with the Subroutines having multiple smaller subroutine within them. I have been drawing a flow chart of the movement of the data - Picasso would be proud - and I seem to have a smaller subroutine which is jumping out of the problematic one and (so far as I trace the flow) does not go back before the problematic subroutine is called again. I'm thinking I need the flow to return to hit that End of Sub marker before it can be called again. Rookie mistake if that is what is happening.
   In terms of using Dos commands, when that wasn't working I checked the wiki on Dos and as Windows 10 wasn't listed I just assumed that was my problem using Kill. I have since found the Command Prompt when I fire up windows, so Dos must be there. Just the statement SHELL, should be all I need to jump into the Dos world?? So step two would be to ID the file and step 3 to just Kill that file? I have zero experience with Dos and will go on the web to search out commands. The file I'm thinking of Killing is in my "j" drive. So I'm thinking I need to do something like SHELL j:GDProblimaticFile\Kill?
  All these years and I have never had to access Dos - I'm hoping the problem is in the data flow.
Thanks again guys

[Pete]

Use Explorer to find the file, and go to the address bar, and copy its full path. That's what you need to kill the file, if it is on a different drive, the complete drive plus path and file name.

The only other thing that prevents a file from being killed on command is if it is a READ ONLY file. That would result in a permission denied error code message.

Pete

[Dimster]

TempodiBasic - your examples work fine. I hadn't realized the Kill statement would work without first invoking SHELL. I have been on line checking out Dos and the potential which SHELL could add to some of the tasks coded into the existing program. Surprising how a new perspective on old coding sweeps over you when you ask someone for help. Thanks again guys.

[euklides]

Perhaps this ???

if the file is already destroyed or is missing, then the kill function will no work.

so I do always so:

Fictokil$="c:\exemple.txt"
close 4:open fictokil$ for output as 4:print #4,"**":close 4
kill fictokill$

[FellippeHeitor]

https://www.qb64.org/wiki/FILEEXISTS

[bplus]

Thanks guys. The offending file was closed - still not sure why the Shell Kill is not working and will explore that but I think I may have discovered a possible cause. The program is complex with the Subroutines having multiple smaller subroutine within them. I have been drawing a flow chart of the movement of the data - Picasso would be proud - and I seem to have a smaller subroutine which is jumping out of the problematic one and (so far as I trace the flow) does not go back before the problematic subroutine is called again. I'm thinking I need the flow to return to hit that End of Sub marker before it can be called again. Rookie mistake if that is what is happening.
   In terms of using Dos command when that wasn't working I checked the wiki on Dos and as Windows 10 wasn't listed I just assumed that was my problem using Kill.  I have since found the Command Prompt when I fire up windows, so Dos must be there. Just the statement SHELL, should be all I need to jump into the Dos world?? So step two would be to ID the file and step 3 to just Kill that file? I have zero experience with Dos and will go on the web to search out commands. The file I'm thinking of Killing is in my "j" drive. So I'm thinking I need to do something like SHELL j:GDProblimaticFile\Kill?
  All these years and I have never had to access Dos - I'm hoping the problem is in the data flow.
Thanks again guys

It looks to me like you, Dimster, think DOS or SHELL has a KILL command, but KILL is only a BASIC command that works only inside BASIC. DELETE is the command for removing files in a SHELL.

And as Pete said, it is possible you hadn't closed the file, so it wont KILL from BASIC nor DELETE from SHELL until file is closed.

[Dimster]

No the file was absolutely closed bplus before I ventured into the Shell/Kill unknown universe - but you are absolutely correct, I completely misunderstood the Kill command being a basic statement v's Shell/Dos. In the past I have always use the "for Output" in situations where new data has changed the relevant values stored in a file which is relied on for calculations within the program.