Encrypted Files Not Being Displayed

Update:

It appears that the first document of each type (pdf, jpg) does not correctly get entered into the database. Once uploaded and saved, the document does not correctly display. When I go back to the 'Edit' tab, the file shows 0 bytes. It is not 0 bytes on the server. If I add another uploaded file or if I delete the current file, then upload a new one, and save; then the file is of the correct size and will display correctly.

It happens independent of the order of uploading a jpg or pdf. It happens for each account. Pre-creating the target directory does not change the result.

More information:

The database entries for the corrupted files in the 'file_managed' table are incorrect. I don't know if this is causing the problem, or just a symptom. The value for 'filesize' is 0 and 'encrypted_files_hash' is NULL.

I've changed the title to more accurately reflect the problem (was: 'Encrypted Files Getting Corrupted')

I have created a new site solely for the purpose of testing 'encrypted_files'. It is the latest core installation plus only 'aes' and 'encrypted_files'. The URL is http://enc.support.realism.com/. Anonymous can create a Basic Page that has been modified to support the upload of a file that is encrypted. I have also modified 'encrypted_files.module' to dump the structure of 'file_info' and 'file' in the 'encrypted_files_file_presave' function. The dumps don't look correct, but I am not sure how to interpret them.

The site will be functional until the problem is solved. I may occasionally delete content or place restrictions on access if there gets to be a problem.

With further investigation, including manual modification of the database, I have determined that the filesize field in the 'file_managed' table is the key to getting this done correctly. The filesize is always set to 0 (default value). When I manually set it to the file size, the decrypting and downloading work correctly.

For a particular case (using the site listed in the previous comment), I get the message (from the modified code) listed below. It appears that a new structure is created for 'file' and the size (and hash) either does not get properly recorded or propagated.

file
stdClass Object
(
    [fid] => 6
    [uid] => 1
    [filename] => page.pdf
    [uri] => ef://page_2.pdf
    [filemime] => application/pdf
    [filesize] => 
    [status] => 1
    [timestamp] => 1380653761
    [encrypted_files_hash] => 
    [rdf_mapping] => Array
        (
        )

    [original] => stdClass Object
        (
            [fid] => 6
            [uid] => 1
            [filename] => page.pdf
            [uri] => ef://page_2.pdf
            [filemime] => application/pdf
            [filesize] => 84350
            [status] => 0
            [timestamp] => 1380653742
            [encrypted_files_hash] => f64b837e666ecf8d1ee07946b228a8cd14b74da56a17a9e76b89047ab3ce1788
            [rdf_mapping] => Array
                (
                )

        )

)

I found a solution.

It appears that when the 'filesize' and 'encrypted_files_hash' fields are copied from the 'original' field into their top-level fields, the module works as advertised. I put the code below just before the end of the 'encrypted_files_file_presave' and 'encrypted_files_file_update' functions.

  if (!empty($file->original)) {
    if (empty($file->filesize)) {
      $file->filesize = $file->original->filesize;
    }
    if (empty($file->encrypted_files_hash)) {
      $file->encrypted_files_hash = $file->original->encrypted_files_hash;
    }
  }

I have no idea if this is sufficient or even the completely correct way to do it, but it does pass all of my tests and work for me.