Per file encryption solution and data loss concerns

Hi all,
I am talking about a per file encryption solution(based on FS minifilter).

The current important concern is the loss of important data of organizations which use this solution. The loss might result by unknown issues and bugs, sudden power loss/ process termination and so on.

The design consists of many fields with variable value and length added to a file as the header and/or footer. This fields might be encrypted or not.

One suggestion is to use a separate file to store header/meta data to cut some undesired effects on data on FS level. This suggestion requires the FS minifilter to hide/manage the existence of the header file.

My specific question is:
how you evaluate the data-header separation suggestion?
Is it easy to handle the separate header file at minifilter level or I will face complicated issues?

The general question is:
How important is the data loss issue in such per file encryption solutions?
What is the good design for overcoming such issue?
What is your suggested design?

> I am talking about a per file encryption solution(based on FS minifilter).

Good luck, expect to take up to a year if you ‘just’ want decrypted data
(i.e. no choice as to whether anyone sees encrypted or decrypted content),
double that if you want multiple views.

The general question is:
How important is the data loss issue in such per file encryption
solutions?

Why the qualification? The question is “how important is data loss?”

No filter should ever corrupt data or render it unreadable because of bugs
(and yes you will encounter many of them)

As to the rest of your questions, I an many others on this list will be
uncomfortable providing you with architectural support, when we have
customers who pay for this: why should they pay for something if you get it
for free? We’ll help you with bugs and internals questions but I’m not
going to design you an architecture.