Has anyone had a cdx file being emp

[John Stephen]

Has anyone had a cdx file being emptied or deleted seemingly from an outide source ? Similar to DELETE TAG ALL but there is no DELETE TAG ALL in my application. Windows Server 2016 and Windows 10 on the LAN
This happens randomly to the point where I had to trap it because data was being compromised. Not good for the client though having to Rebuild indexes every two weeks or so.
Thanks, John

 

[Olaf Doschke]

The only other code from inside that could cause this is REINDEX and PACK. Both will cause the CDX to be rewritten based on the "empty" header with all the index tag names and expressions.

And I'd guess on antivirus intercepting that this time, not oplocks.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[John Stephen]

Hi Olaf, this is a multi user system and Reindexing, Pack and all other things that require exclusive use will not run while users are logged on. The problem happens in the middle of the day (I log time, date, operator and the form that is open) when all users are logged on. I was wondering if an antivirus app took it unto itself to clean out a cdx. Unlikely because it is always the same cdx's out of dozens that are running. I also wondered if some of the expressions in the tags were too complex, but one is very simple. Interestingly it is always the same two users who catch the error but that is probably because they are the most likely to be saving data when the event occured (or soon after). Not like it is an overnight teminals left logged in either because it happens more towards the middle of the day.
Cheers, John

 

[Olaf Doschke]

Then you should perhaps use procmon to monitor the CDX file and see what acts on it and when it shrinks.

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

http://support.veryant.com/support/phpkb/question.php?ID=136

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

If it turns out the file shrinks from access of your own application process, besides REINDEX And PACK also ZAP would do that, if you use that to zap grid cursors but have the wrong workarea selected, for example, whatever. Unfortunately, procmon won't know what code executes.

Then you can also run coverage logging, but it's not necessarily the two users, who experience the problem, that also shrink the file somehow. Which means coverage logging for every user and analyzing all logs. That'd be a heavy debug workload.

Another strategy you could use is to create a new process running somewhere on the server itself, for example, which keeps the table open set to some index. It can be quite idle, just using the file SET ORDER and seek something, so you're sure the CDX is used and then READ EVENTS. Then any operation which would need exclusive access to shrink the CDX would fail and that can also be captured with procmon.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[GriffMG]

Is there any data still in the .dbf and .fpt files?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[John Stephen]

THanks for all the suggestions, but a couple of answers:
Yes all data is intact
This is not a one off application, it is running in the same exact form on at least 25 other sites, but of course there could be a sequence of events these two users have discovered that I have found yet in te 20 years this app has been in use.
There were a couple of DELETE TAG ALL on cursors but I have since disabled them
You have given me some ideas though, whatever is doing this would need exclusive access so that theoretically means that it couldn't happen while users are active (at least while having those two forms and their tables open)
I think I will build a small app to run continuously on the server to get the time that that the shrinkage occured, maybe try Procmon.
Thanks again

 

[Olaf Doschke]

There are always ways to hack into access, for example, there is that unlocker tool. It's able to delete those file handle entries on the file server side and procmon wouldn't detect that, as that's not acting on the file itself but on the metadata about it usually protecting it. There's all kind of flaws that wouldn't need human intervention and intentional damaging. Even those, who intentionally want file access most of the time don't want to do harm, but do things like virus scanning or backup, especially if they are locked out from even reading the files.

So you could check whether you're doing all file access in shared modes, set exclusive off in any data session and don't ever use any USE of a table or OPENing of a DATABASE exclusively, also FLOCKs and FOPEN with exclusive modes. That would raise the need for such actions. Any such file operations should be separate, as you tell you only reindex, pack etc in the after hours. But have you looked into such routines hanging? Are there scheduled tasks doing such things?

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[John Stephen]

No nothing ever gets opened in exclusive mode, there are no scheduled events. The rebuild function can't operate if any users are logged on because it checks first to see if it can get exclusive access to the main company table and the app can't run without the main company table being open. I am putting a log in to see what time of the day it happens so we can check if any scheduled events happen at the same time. Ironically this has only started since a new tech and a new server was installed. I can imagine that they are using different backup and anti virus systems.
If we can't crack this I will ask them to reveert back to using one of the workstations as a server to see if it is something on the server that is causing it.
Cheers
John

 

[Olaf Doschke]

>No nothing ever gets opened in exclusive mode

You are also aware, that a USE some.dbf without EXCLUSIVE option can still open it exclusive when the session is with exclusive ON, I assume. Anyway, that alone doesn't empty a CDX. But it's easily overlooked some settings are session dependent and if you just make some settings in you main.prg you only make them for session 1 and this is less known because defaults are sensible including exclusive is off.

I've also seen programmers stepping on their own feet as the VFP IDE setting of exclusive is OIN by default and developing with the company database in your source project doesn't even immediatelys become an apparent problem, as you rarely get exclusive access. But when you do, users in production will fail.

In your situation I assume you don't work in house, you work off site on your own and disconnected, but is someone in the company having VFP for maintenance not aware of this dangerous setting?

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[John Stephen]

No I work extensively in house, nobody else has access the the code. I must say that in 20 years of working with the same application with 25 users each with an average of 15 or more workstations over LANS, WANS and even two running in the cloud I have never encountered anything like this and you can imagine in 20 years I have seen a lot. Not saying there won't be new ones crop up, there always will be.
I just wondered if anyone else had encountered it. In the end I will probably check at form level and if necessary and I can get a lock I will pause and reindex it there and then.
Thanks for your interest and suggestions, much appreciated
Cheers John

 

[Olaf Doschke]

>No I work extensively in house, nobody else has access the the code.

Well, the question then is: Do you have set exclusive off in your IDE? And do you work on separate development and test data?

The only regular CDX corruptions I had was definitely with oplocks and way back then the simplest solution was Windows Server 2003, that wasn't the newest Server OS back then, but it wasn't far after 2003 when this was quite a new thing.

And the files there weren't empty (or just header size), the index tags just had errors very often apparent from SEEKs and Rushmore optimized queries and then REINDEXINg helps, but only is of short term help.

It was fortunately in a system only used by a few select users in that company, but of course, also the more important users, having to do with the final decisions of whether a developed product would go to the market.

Anyway, CDX corruptions, yes, but in that form, I can only imagine that to happen by operations doing index rebuilding, which includes all the things I already mentioned from REINDEX over PACK and ZAP and the only thing else would be ALTER TABLE. Besides exclusive access necessary to make a similar alteration, but then the question would be why?

I still strongly suspect antivirus freezing that state of the file as it is an alarming thing if a file is truncated like that and begins to rewrite. And there is client side and server side antivirus and intrusion detection software and software and hardware firewalls.

Only when rebuilding a CDX you go through the stage the CDX is just its header. The first thing written out to a new file is the header information. As that's what you see as files, I can only imagine that it comes from inside of the VFP IDE or some action of your application or helper tools you wrote. That doesn't happen randomly, that doesn't happen as network error regarding a block of the file or as file corruptions in the index tree structures. That happens when the CDX files are rebuilt. Why should the CDX be like that for any other random reason?

I mean, you could take such a corrupted file and compare it to the file you get when you ZAP a healthy version of the table. Is it really exactly like you describe, are the CDXes exactly that header part or are they perhaps the first file block? There will be a difference, even though much of VFPs file structure has sizes equal to the file block sizes of that era, a CDX header has a varying size, not necessarily in multiples of 512 bytes (Windows Explorer makes the distinction of logical file size and file size on disc in blocks, as you know and CDXes usually have a logical file size not in multiple of hdd file system blocks).

At several times I also suggested backing up the CDX files in that empty state is a good way of healing indexes aside from a clean solution to delete all tags and rebuild them with VFP code. But putting back CDX in this empty state alone isn't healing corrupt CDXes, obviously. It's only the first step before a REINDEX then can take that CDX information and the still healthy DBF and FPT to recreate the full CDX with all it's index tag trees.

So if anybody in your company did that and took it from my recommendation, please forgive me, but then they didn't understand me very well. It is a way to make good use of REINDEX, as REINDEX only fails on corrupt CDX headers and that's why several experts recommend to never use the REINDEX command, you can use it with a healthy CDX header and you can be sure a fresh CDX is healthy. So if you make backups at the point a table was new and empty (or small) you have the bare minimum healthy file piece you need to recreate the whole bunch of indexes with REINDEX. It's still an operation you can only do with exclusive access, even though the process only needs write access to the CDX file, its the way VFP choose to limit such operations. So it's still not a repair option on the fly and during the course of the day.

Which reminds me of a last thing worth mentioning: I had a mechanism in place to end an application by administrative needs to do so, a timer listening for a sign to sign off. And that wasn't a sudden quitting of the apps nor shutting down the server and letting everybody crash, it started off with informing any user the system will go down for maintenance and they have 5 minutes to save important changes and exit themselves or get shut off after that grace period. With repeated alert every minute. Obviously in a nonmodal way, as the message box was extended with the timeout parameter that was very welcome as it would still appear in its modal state overriding any other action a user did and being noticed, still ending itself to allow the timer to become active again and finally shut down the app. It's helpful to have such a mechanism for the on-site administrative personnel.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[John Stephen]

I agree wholeheartedly,I never use reindex and indexing is done manually by the master password holder and can't be run without gaining exclusive use of the main header company table. I also have an external app which deletes all the cdx files and rebuilds the indexes from scratch but once again it can't get exclusive access if the main header is in use. I created this so that users can do a rebuild on other companies within the system if they are not in use to save kicking everyone off.
Cheers, John

 

[Olaf Doschke]

The con I have against recreating tags is the problem INDEX ON doesn't allow you to generate a primary index. And a CDX header simply has all the indexes the table has. It only doesn't work well in situations the index tags are subject to change often, but then I question the database concept. Updates are part of upgrading applications, but if you have regular changes in your data model that concept could be adjusted. Even talking about tables used for monthly business intelligence questions. Fine, create them. In a separate DBC.

Anyway, I'd be curioos if the shoirtened CDX files you experience really are exactly the header of the CDX files.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name