search

jetwhiz / encfs4win

Windows port of EncFS
https://encfs.win
Other
401 stars 41 forks source link

corrupted file - Errno 22 Invalid argument #137

Closed clach04 closed 4 years ago

clach04 commented 4 years ago

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).

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):

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 commented 4 years ago

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 commented 4 years ago

Error seen in Windows explorer when copying file:

Interrupted Action
 Invalid MS-DOS function.
stale[bot] commented 4 years ago

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 commented 4 years ago

Any extra information I can provide?

jetwhiz commented 4 years ago

Hi @clach04,

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

clach04 commented 4 years ago

@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.

jetwhiz commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@jetwhiz sanity check - related to https://github.com/vgough/encfs/issues/145 ?

jetwhiz commented 4 years ago

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[bot] commented 4 years ago

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.