|
|
Post by Stefan on Mar 10, 2021 6:01:13 GMT -5
Robert - I'll gladly help you look for watch out for such corruption... where do the iffy files appear?
|
|
|
|
Post by George on Mar 10, 2021 10:37:50 GMT -5
Guys:
All I can tell you is what I do. It doesn't explain what's happening, but if you see a loophole in what I'm doing please speak up. I'm as frustrated as you are that this is still happening.
SPFLite create UNDO files (If SETUNDO > 0) when a file is loaded. It creates them in sets of 4 based on the SETUNDO value. e.g SETUNDO=10, there will be 40 files created.
The filename is created by a Windows API that guarantees to create a unique filename that doesn't duplicate anything currently existing in the folder.
The folder to use is also provided by a Windows API to point to the system's normal TEMP folder. Note that it comes from an API, not by SPFLite scanning the system variables.
The names will all be formatted UNDhhhh.tmp The UND is provided by SPFLite to the API, the hhhh.tmp are HEX characters provided by Windows. Now there is a provision where if the API fails (not sure under what conditions that could ever happen) the API is called again to retry in the current folder. If THAT fails, a popup error will occur.
The UNDO logic rotates usage through the assigned files, and the files are all deleted at close time.
There is also cleanup logic at start-up to clean any old UNDO files that may be left by crashes etc.
So, where is that process do you see the error occurring?
Because staring at that code over and over is not going to fix this.
George
|
|
|
|
Post by George on Mar 10, 2021 14:32:28 GMT -5
Well, what you're saying is that perhaps a data area is being clobbered. The area containing the UNDO filenames is just one array amongst over 275 other tab related data items. If it was a random data corruption, then it certainly wouldn't be being clobbered with random data that just also happens to be valid enough to create a filename somewhere in the system. If it's being clobbered with some reasonable filename format data, then it would have to be done by some UNDO related code which would understand the format of the UNDO control array. So I'm attaching all the code routines involved in writing out UNDO data, if you feel like reviewing it. Note the API GetTempFilename actually allocates, opens, closes and frees the file. So all these files are created at that point, and subsequent UNDO data writes are all overwriting the previous file. I'm not trying to palm this off, but I've reviewed this stuff so many times I may be blind to what's wrong. George UNDO Code.BAS (12.19 KB) |
|
|
|
Post by George on Mar 11, 2021 15:44:57 GMT -5
Robert: Yes, I wondered as I was collecting the code fragment why I bothered with getting the short name, after all, they're just stored in a table.
But as for the prefix, if I got a random prefix, that would shoot down the auto cleanup of orphaned UNDO files at startup.
Removing the short name stuff is fine with me, I don't remember why it was there anyway.
George
|
|
|
|
Post by Stefan on Mar 12, 2021 7:00:03 GMT -5
Robert, I have searched all my drives for file names that start with 'UND' and can find none that match your description. I wonder if this 'bug' is triggered by something unique(ish) in your SPFLite setup. I believe the UNDO level count is set in every file type/profile. For what it's worth, I operate with UNDO level at 10 for some files and 20 for most others. Default profile attached: PDEFAULT.TXT (606 B) |
|
|
|
Post by George on Mar 12, 2021 11:03:59 GMT -5
Robert: I don't understand what you mean by the API only doing 40% of what I need? What items are in that missing 60% ?
It assigns a Windows guaranteed unique name. This is not bothered by multiple SPFLite instances. It allocates, Opens and Closes the file (i.e. creates a Null file) What on earth more could you ask of it?
And because it uses the standard system TEMP folder, even if the SPFLite built-in UND file cleanup failed to do it's job, any normal system cleanup function would kill the files because they are in the normal TEMP folder. Nobody has to worry about "Are these files valuable or not?"
So what on earth would I gain by doing all that work to get to your suggested solution?
George
|
|
|
|
Post by mueh on Mar 12, 2021 12:21:31 GMT -5
George: I also like using the windows API for generation of the filename since it allows to direct the tmp files away of SSD drive ( limited space ) .
To clarify : Windows API uses the TMP Environment Variable . If not there the TEMP Environment varaiable path . Normaly they point to Temp folder .
If TMP environment variable path is not existing the UND*.tmp files are directed to the Edited file folder .
Verified this by deleting TMP envirnment variable or SET it to invalid path before calling SPFLite .
I never saw this problem Robert describes .
Thanks
|
|
|
|
Post by George on Mar 12, 2021 13:11:28 GMT -5
MUEH: Robert:
I really can't work up too much concern for any user who doesn't have TMP/TEMP set to whatever they consider a 'reasonable location'.
Robert: So should I also start doubting all the rest of the Windows API's that are used "in case they don't work as advertised".
I've seen no examples of GetTempFilename not doing it's job - ever. I'm sure that API is called probably billions of times a day, by all kinds of software, in all kinds of systems around the world. If there were a problem with it I'm sure it would be reported by somebody, somewhere. But you'd like me to second guess it and create my own DIY version?
I understand the frustration of these unwanted files, but to make this change, without any proof that the API is the cause is not the way. What if I did all the changes, and you STILL were having the problem?
George
|
|
|
|
Post by George on Mar 13, 2021 10:39:27 GMT -5
Robert: I'll certainly give that a look. As you say, anything's possible.
Had a review. The creation of the UNDO files is a basic call in every function that opens files (EDIT, BROWSE, etc.)
So I've added a test in the UNDOSAVE routine to see if the contents of the filenames appears valid. It's a simple check to see if the name contains "\UND" within the name. If it fails, a pop-up will appear to notify the user, and the writing of the UNDO data will be skipped.
That's the best I can offer at this point. If SPFLite is only writing to \UNDxxxx.tmp files, and your rubbish file names are some other format, then UNDO cannot be the culprit.
George
|
|
