corrupted file - Errno 22 Invalid argument

Question

corrupted file - Errno 22 Invalid argument

clach04 opened this issue 5 years ago · comments

Describe the bug

I can NOT reproduce this bug for new volumes. I have an existing volume where it always fails when reading from a file. Luckily, I have a backup of this file. Fails with:

Errno 22 Invalid argument

Running builtin OS tool "net":

C:\>net helpmsg 22

The device does not recognize the command.

Originally saw with 7z, Windows Explorer COPY, and Adobe Reader when attempting to open/read a PDF, reproduced with a simple python script that walks directory tree and reads contents of all files. Attached in case its remotely useful (rename, Github allows text not python script attachments).

dumb_file_walker_reader.txt

This was seen with encfs-installer_v1.10.1.exe, I upgraded to encfs-installer_v1.11.0-beta.1.exe and still seeing the same problem with the same file, in the same volume.

Desktop (please complete the following information):

OS: Microsoft Windows [Version 10.0.17134.1006]
Processor architecture: i7 (64-bit x86)
Encfs4win version: v1.10.1 and v1.11.0-beta.1
Dokan version: v122 (according to about dialog)

Additional context

I'm using Z: as my virtual drive.

I tried to reproduce by creating a similar volume (W:), with the same file. Was not able to reproduce.
Not sure if this is a read herring, Adobe hates opening PDFs from a encrypted drive (at least the 2nd test one I created). Firefox opens the test pdf fine but Adobe fails with no clear error text.not sure if that means Adobe has expectations about file access - mentioning it case anyone else hits this. Initially I assumed this was an Adobe problem but then saw with other tools. Adobe Acrobat Reader DC version 2019.021.20048 fails with error text, "There was an error opening this document. Access denied."

Happy to take diags to try and help progress.

clach04 · Answer 1 · Mon Oct 21 2019 12:09:12 GMT+0800 (China Standard Time)

All other files are fine, it is this single file. I have a backup of this file from 2019-10-17 which was created with 7z. The meta data for the problem file claims it was last modified 2018-01-18.

Using encfsctl.exe get:

2019-10-20 21:06:48,412 ERROR Invalid data size, not multiple of block size
2019-10-20 21:06:48,421 ERROR decode err: block decode failed in filename decode

clach04 · Answer 2 · Tue Oct 22 2019 12:08:29 GMT+0800 (China Standard Time)

Error seen in Windows explorer when copying file:

Interrupted Action
 Invalid MS-DOS function.

stale · Answer 3 · Sat Dec 21 2019 12:19:45 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

clach04 · Answer 4 · Sat Dec 21 2019 22:17:14 GMT+0800 (China Standard Time)

Any extra information I can provide?

Charlie Munson · Answer 5 · Tue Jan 07 2020 11:08:07 GMT+0800 (China Standard Time)

Hi @clach04,

Which settings are you using for this setup? Is this pedantic mode, and are you using Block or Block32 encoding?

clach04 · Answer 6 · Wed Jan 08 2020 10:43:52 GMT+0800 (China Standard Time)

@jetwhiz I think the answer to both is no. What's the best way to get you the answer you need? I suspect you need to see extracts of the .encfs6.xml file (but not the secret pieces).

Does the extract below help?

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="15">
<cfg class_id="0" tracking_level="0" version="20">
    <version>20100713</version>
    <creator>EncFS 1.7.4</creator>
    <cipherAlg class_id="1" tracking_level="0" version="0">
        <name>ssl/aes</name>
        <major>3</major>
        <minor>0</minor>
    </cipherAlg>
    <nameAlg>
        <name>nameio/block</name>
        <major>3</major>
        <minor>0</minor>
    </nameAlg>
    <keySize>256</keySize>
    <blockSize>1024</blockSize>
    .....
    .....
</cfg>
</boost_serialization>

I've not had a re-occurrence, I ended up to resolving this by wiping out the problem file.

Charlie Munson · Answer 7 · Mon Jan 13 2020 21:32:09 GMT+0800 (China Standard Time)

For future encfs systems on Windows you'll probably want to switch to using block32 instead of block for filename algorithm. Block32 is designed for case-insensitive filesystems (e.g., Windows) but also works on case-sensitive systems (e.g., Linux). Using block on Windows can result in issues where files cannot be accessed.

It's also possible that one file may have gotten corrupted somehow and made it unreadable.

clach04 · Answer 8 · Sun Jan 19 2020 05:03:00 GMT+0800 (China Standard Time)

@jetwhiz good to know. Follow up questions (some of these may lead to enhancement requests). Where is this specified in the .encfs6.xml file? Is it:

    <nameAlg>
        <name>nameio/block</name>
        <major>4</major>
        <minor>0</minor>
    </nameAlg>

I just created a new drive/folder using the encfs4win version from above and I didn't see a place in the dialog that controls that. Should this be an enhancement request (either pick a better default and/or offer a way to set at creation time)? Full generated test file below (password was test, location C:\tmp\delete_encfs_test):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="7">
    <cfg class_id="0" tracking_level="0" version="20">
        <version>20100713</version>
        <creator>EncFS 1.11.0-beta1</creator>
        <cipherAlg class_id="1" tracking_level="0" version="0">
            <name>ssl/aes</name>
            <major>3</major>
            <minor>0</minor>
        </cipherAlg>
        <nameAlg>
            <name>nameio/block</name>
            <major>4</major>
            <minor>0</minor>
        </nameAlg>
        <keySize>192</keySize>
        <blockSize>1024</blockSize>
        <plainData>0</plainData>
        <uniqueIV>1</uniqueIV>
        <chainedNameIV>1</chainedNameIV>
        <externalIVChaining>0</externalIVChaining>
        <blockMACBytes>0</blockMACBytes>
        <blockMACRandBytes>0</blockMACRandBytes>
        <allowHoles>1</allowHoles>
        <encodedKeySize>44</encodedKeySize>
        <encodedKeyData>
QN0Hn6SvtDmrsxROwoHp8mOw139LVb8rqWJHhGpysE97d9Zkhq7YS/osRHU=
</encodedKeyData>
        <saltLen>20</saltLen>
        <saltData>
XPQUSBUVIEmciKUi6KPYFhfNc04=
</saltData>
        <kdfIterations>262245</kdfIterations>
        <desiredKDFDuration>500</desiredKDFDuration>
    </cfg>
</boost_serialization>

Any recommendations? I'm guessing generating a new encrypted volume is the best way forward. Any comments on the idea of copying existing config file into a new folder, editing to become <name>nameio/block32</name> and then mounting that volume, copying files and then using that moving forward?

clach04 · Answer 9 · Sun Jan 19 2020 05:06:03 GMT+0800 (China Standard Time)

@jetwhiz sanity check - related to vgough#145 ?

Charlie Munson · Answer 10 · Mon Jan 27 2020 11:24:19 GMT+0800 (China Standard Time)

Hi @clach04

The latest version of encfs4win now uses this setting (Block32) as the default. This is available in v1.11.0-beta.2 or v1.10.2.

I would recommend creating a new encrypted volume and copying your files into it, since this value in the config cannot be changed after you already have files encrypted in nameio/block mode without removing all of the previously-encrypted files.

stale · Answer 11 · Fri Mar 27 2020 12:18:41 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.