Test for missing file

[turtleman]

I have nearly 2 dozen files selected in a combobox (1-23) that's working fine, with each file consisting of 12 lines of sequential data. But knowing how "stuff" happens, is there a simple test to check if the selected file is missing or corrupted so a default file can be substituted? I thought I had a solution a year or so ago, but darned if I can find it. Thanks!

[Walt Decker]

There are a few ways:

1. Look up FILES in the help.

2. open the file for input using an error trap. If the file exists there will be no error.

3. Use the DIR.DLL found in the thread APIs and DLLs and activate function FN.File.

4. Use Kernel32.dll to look for the file.

[xxgeek]

Here is an example to work with. You will need to loop through it with your 12 files.
If data is not the same in both files, the file being checked will be replaced by the known good file.
As stated by Walt Decker, there are many other ways.

Corruption? - not checking for that, but checking for difference in data.
Interesting to know if and how to check for corruption. Maybe someone else knows.


'This code will check for a file and replace if not exist, or overwrite with known good file.
'If both files contain different data the known good file will replace the bad one.

'origFile$ = name of file being checked for existence and corruption
'origDir$ = path to folder containing origFile$
'spareDir$ = path to folder containing spareFile$

    dim info$(0, 0)            ' a must  - info$() creates an array - auto redims as necessary
    origDir$ = "name of file being verified exists"      ' eg: "myfile.dat"
    origFile$ = "path to folder containing origFile$"   ' eg: "c:\Files\MyDataFiles
    spareDir$ = "path to folder containing good file"
    spareFile$ = origFile$                              ' both files use same name
   files origDir$, origFile$, info$()
 if val(info$(0,0)) = 0 then                    ' if file not exist - replace with spare
      open spareDir$;"\";spareFile$ for input as #2
      open origDir$;"\";origFile$ for output as #1
      #1  input$(#2, lof(#2));
      close #1
      close #2
 else                            ' if file exists - compare to spare - replace if not same
       open origDir$;"\";origFile$ for input as #1
       origData$ = input$(#1, lof(#1)) : close #1
       open spareDir$;"\";spareFile$ for input as #2
       spareData$ =  input$(#2, lof(#2)) : close #2
     if spareData$ = origData$ then wait 'if data is same in both files either wait or do something else here
       open spareDir$;"\";spareFile$ for input as #2     ' copy spare file to original location
       open origDir$;"\";origFile$ for output as #1
       #1  input$(#2, lof(#2));
      close #1
      close #2
 end if

end


[Walt Decker]

In order to check for corruption you have to store a CRC (check-sum) for each file. This would be in the form of a file with the full path and file name followed by the CRC. The easiest way to produce a CRC is to load the file, parse each byte, and add the ansi value to a total variable, e.g:

FOR I = 1 to LEN(FileStr$)
Total = Total + ASC(MID$(FileStr$, I))
NEXT I

In order to check the file for change or corruption you have to load the file bytes into a string, parse the file bytes as above and check that against the stored CRC. Be advised that, if there is a difference, there is no way to tell whether the file is corrupted or just changed.

PS:  There are more sophisticated methods, some of which will actually point to corruption, but the above is the simplest.

[tsh73]

Just to add, there is a function
fileExists
in a Help file
Here it is in (old) online help
www.libertybasicuniversity.com/lb4help/38L5ZGN.htm

[Rod]

Do you need two dozen files or would one file with two dozen records suffice?

[turtleman]

Thanks for all the suggestions which brings up a more basic issue that probably applies to most programs. If files are initially populated when the program is first installed, everything runs as it should, and each file's data can then be changed and stored. No problem. However, in the course of program development, if a file ends up holding more or less than the expected number of lines, or if the file is missing or empty altogether, the program crashes.

So the fundamental questions: What is the "normal" method for handling missing or incorrect data? Are files normally checked and default data loaded on error detection? Or is it just assumed that nothing gets screwed up to being with? Maybe I'm trying to fix a problem that doesn't need fixing! Very confused.

[Walt Decker]

If the app depends on those files for initialization or whatever they should be in a hidden directory with hidden/system/read-only file attributes and should never be modified by the app or the user. That limits the possibility of becoming missing or corrupted. If they require a re-write or modification during app operation a duplicate of the original files should be placed elsewhere and the duplicate modified using some "magic" number as a header when the duplicate is modified.

As far as missing or incorrect data handling, the only way to tell is by comparing the duplicate with the original. If you allow the app to modify the duplicate, how are you going to determine whether the data is actually missing or incorrect?

[Rod]

On a modern system you are very very unlikely to get a file error, indeed not at all. Any error will be introduced by your own programming. So my view is overkill , overthinking. You don't need twenty four files, that's twenty-four opportunities to make an error. Use one file with twenty four records.

You do need to check the file exists, and you should substitute a default file if the run is the initial run or perhaps the user has deleted the file. So the file exists hints are good. CRC, overkill IMHO. If the program was securing Crypto Currency fair enough but game play and such needs less work.

[Chris Iverson]

Oct 7, 2022 5:59:28 GMT -5 turtleman said:

So the fundamental questions: What is the "normal" method for handling missing or incorrect data? Are files normally checked and default data loaded on error detection? Or is it just assumed that nothing gets screwed up to being with? Maybe I'm trying to fix a problem that doesn't need fixing! Very confused.

It's all up to you, but personally, I prefer to code defensively. I would sanity check the data from the file first, and if there was an issue, inform the user and start with default data.

[Walt Decker]

It would really help if you provided some code and the files in question. Mostly, we are all making suggestions from a black box.

[turtleman]

This is embarrassing, but upon closer examination, I already had error checking incorporated into my program! It's been over a year since I dealt with that section of code and had simply forgotten. (What can I say? I was heavily distracted selling my home in Atlanta and moving to Florida.) The software "problem" started a couple months ago when I modified another program segment that shared some of the same code, but BEFORE the error checking routine. A simple repositioning fixed things.

My spaghetti code doesn't lend itself to posting without extensive simplification, which is the main reason I haven't included examples. Sorry for the false alarm and thanks for everyone's help.