A limitation of Archive Center

FileArchiveCenter has a limitation: only ascii encoded files work,
even though it should not.

For archiving process, it is no problem with file binary content all the way down to the disk. However, when it comes to retrieving a file, it doesn't work that way. Here is how it works:

An archived file first get read by GpgWrapper, which reads the file decrypted content from the console output in text format and returns it as a string.

Then, the ArchiveManager encodes the content into binary with ASCII standard encoding:

return Encoding.ASCII.GetBytes(strFileContent);

Next, the binary is passed through soap protocol to the client, behind the scene, it is converted into text and back to binary with Base64 encoding, because soap is a text based protocol.


Finally, the client proxy class convert the binary back to string with ASCII encoding,

ASCIIEncoding encoding = new ASCIIEncoding();
return encoding.GetString(fileBinaryContent);

Clearly, with this process, only ascii files work. It is a limitation.

To solve the problem, two preconditions are to be met:

1. GnpPGWrapper rather return the decrypted binary then the console output of text; but it needs to seek a way let the GnuPG commandline out a decrypted file in a temp location;

2. Based on the binary stream of a file's content, .Net framework has the function to discover the encoding - it makes sense that .net has this sort of function.

Now that we can successfully refactor the code to archive text file with any kind of encoding. Bear in mind, we have to check all the client application which retrieve files from archive service, because we changed the damn interface!


By Kevin Luan
April 15, 2008