skipping this file because the filename structure is not unknown...

[ostasevych]

Hi!

I am trying to use your recovery tool to decrypt the e2e encrypted files. Getting the error skipping this file because the filename structure is not unknown...

What can be wrong?

[yahesh]

@ostasevych Oh, good catch! That debug message should read "skipping this file because the filename structure is not unknown...".

This is not an error message but purely informational. As the recovery script does not use the database to identify actual files, it uses the filename structure instead to distinguish between actual files and metadata. That information is there to let you know that the script did not try to decrypt the file because according to the filename structure it's some metadata file instead.

[ostasevych]

Ok, The whole picture: I have somehow deleted the encrypted files in the folder Secured in nextcloud, which have been e2e encrypted.

I have a backup of the files as of yesterday:

• the encrypted files
• and metadata.

So, I have placed the folder with the backup with encrypted files on the place, where the deleted files were residing earlier /data/files/myusername. And I have placed the metadata from the backup to the folder /data/appdata_****/end_to_end_encryption/metadata.

Apart of that I copied the encrypted files in the folder src and created a folder dst for the results.

NC Desktop client shows crossed lock and hex name of files.

Running your script as recover.php ./dst ./src with debug mode enabled I am getting:

DEBUG: debug mode enabled
DEBUG: DATADIRECTORY = '/data'
DEBUG: DEBUG_MODE = true
DEBUG: DEBUG_MODE_VERBOSE = true
DEBUG: EXTERNAL_STORAGES = array (
)
DEBUG: USER_MNEMONICS = array (
  'myusername' =>
  array (
    0 => 'mymnemonic',
  ),
)
DEBUG: userkeys = array (
  0 =>
  array (
    'file' => '/data/appdata_***********/end_to_end_encryption/private-keys/myusername.private.key',
    'mnemonics' =>
    array (
      0 => 'mymnemonic',
    ),
    'name' => 'myusername',
  ),
)
DEBUG: loaded private key for myusername
DEBUG: metadata = array (
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/428696/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/428772/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/431602/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/431607/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/431628/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/431800/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/439601/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/439606/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/439623/meta.data
DEBUG: metadata file has wrong structure
DEBUG: metadata file has wrong structure
DEBUG: metadata file has wrong structure
DEBUG: metadata file has wrong structure
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/764993/meta.data
DEBUG: metadata file has wrong structure
DEBUG: metadata file has wrong structure
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/765608/meta.data
DEBUG: loaded metadata from /data/appdata_***********/end_to_end_encryption/meta-data/765616/meta.data
... cut ...
DEBUG: sources = array (
  '' . "\0" . '0' => '/home/myusername/recovery/src',
)
DEBUG: filename = /home/myusername/recovery/src/Secured/2c79e86adea94235a6ab74fc95935b7f/75bd9b0c167f4ae6be715f839e8e4ff1/7d12c8ca450a4823acf8eb0b550e5c1b
DEBUG: targetname = /home/myusername/recovery/dst/y/src/Secured/test folder/subtest/new 5.txt
DEBUG: parsed = array (
)
DEBUG: skipping this file because the filename structure is not unknown...
DEBUG: filename = /home/myusername/recovery/src/Secured/2c79e86adea94235a6ab74fc95935b7f/75bd9b0c167f4ae6be715f839e8e4ff1/a9bbceaa56074b2abdee45928a0e890e
DEBUG: targetname = /home/myusername/recovery/dst/y/src/Secured/test folder/subtest/tyt.bmp
DEBUG: parsed = array (
)
DEBUG: skipping this file because the filename structure is not unknown...
DEBUG: filename = /home/myusername/recovery/src/Secured/874a54c47d2b4ce79f94ebc11e6ffb69/042372c68eaa42febffa6a776868452a/321e4f6553554d42a355bf52ffacc758
DEBUG: targetname = /home/myusername/recovery/dst/y/src/Secured/Folder A/info/Work.pdf
DEBUG: parsed = array (
)
...

The folder dst remains empty after running this script...

How to make it working?

[yahesh]

@ostasevych Your data directory is called /data but you use /home/myusername/recovery/src as the source. The source(s) need(s) to be located within the data directory.

[yahesh]

@ostasevych I've seen that you have some debug entries like DEBUG: metadata file has wrong structure. Would be great to learn how these look like. They're either broken or have a structure that I haven't seen before.

[ostasevych]

@ostasevych Your data directory is called /data but you use /home/myusername/recovery/src as the source. The source(s) need(s) to be located within the data directory.

Well, according to you that is not so clear. I may not know the exact location of the file:

<sourcedir>  this is the name of the source folder which shall be decrypted, the
        # (OPTIONAL)   name of the source folder has to be either absolute or relative to
        #              the current working directory, if this parameter is not provided
        #              then all files in the data directory will be decrypted

I managed to get the result by dirty patching

1376   if (1==1) {

[ostasevych]

@ostasevych I've seen that you have some debug entries like DEBUG: metadata file has wrong structure. Would be great to learn how these look like. They're either broken or have a structure that I haven't seen before.

I have checked them: they contained only checksum, metadataKey without the reference to a file... So, probably, orphans.

[yahesh]

@ostasevych

Well, according to you that is not so clear. I may not know the exact location of the file:

That's why I improved the documentation in https://github.com/nextcloud/encryption-recovery-tools/pull/34. Normally you don't have to provide the name of the sourcedir / sourcefile and instead just decrypt all of the files by omitting the parameter entirely.

I managed to get the result by dirty patching

I really don't know what this is supposed to tell me.

[ostasevych]

@ostasevych

Well, according to you that is not so clear. I may not know the exact location of the file:

That's why I improved the documentation in #34. Normally you don't have to provide the name of the sourcedir / sourcefile and instead just decrypt all of the files by omitting the parameter entirely.

If I commit this parameter it scans tons of my data, including group folders etc...

I managed to get the result by dirty patching

I really don't know what this is supposed to tell me.

Ah, it is just to say, that it is possible to decrypt data saved locally. I mean, in particular cases it may be good to have option to recover data from locally provided inputs, eg data and metadata. So, a user may copy from the server in his own folder both metadata and data and restore them by providing the mnemonics.

[yahesh]

Ah, it is just to say, that it is possible to decrypt data saved locally. I mean, in particular cases it may be good to have option to recover data from locally provided inputs, eg data and metadata. So, a user may copy from the server in his own folder both metadata and data and restore them by providing the mnemonics.

Yeah, sure. Just copy those in the same directory and set that directory as the DATADIRECTORY. No dirty-patching needed.

I guess this is fixed then.

P.S.: Even the documentation reads:

DATADIRECTORY - [...] if you copied or moved your data directory then you have to set this value accordingly [...]