Sync conflits support for --reversewrite [PATCH]

[axet]

Hello!

Using encfs with --reversewrite allows to two way sync files online. This mode also benefits from filesystems with compression support (since encrypted files can not be compressed due to entropy == 1) since files stays on drive not encrypted!

But here a two issues with --reversewrite and online syncing:

1. files in cloud does not have ".encfs6.xml" config file. Adding it to the cloud, prevent it synching back with Input Output error since this file does not have a valid fileencrypted file name. Would be nice to have option allow overwriting ".encfs6.xml" using reverse encrypted folder in reversewrite mode.

2. files changed on two machines can produce conflict files. Most syncing software rename those files with name template like this "original name (1)" or "original name (sync conflict 1.2.2022)". Basically adds a suffix to the name. Having option to allow such files created and automatically show those files under decrypted folder would make much easier to solving sync conflicts. Right now such files producing Input Output errors.

Thanks for amazing and inspiring project!

[axet]

I prepared two patches.

1. First patch showing '.encfs6.xml' in --reverse and --reversewrite modes which allows to sync this file back and forth from mounted folder (encrypted). Changing file in encrypted folder change it in local filesystem. It is working, but code can be more optimized:

• https://gitlab.com/axet/homebin/-/blob/debian/cdebian-dget.d/bookworm/encfs/encfs-cfg-xml.patch

2. Second patch supports for handling sync conflicts. It doing that by adding "[encfs-corrupted]" to the file names.

Corruptions comes from incorrect file name during sync. For example when sync app create duplicate files in your encrypted (--reversewrite) or normal encfs mount directory with suffix to the file name. Corresponding file in the encfs mount (encrypted or decrypted depending or --reverse option) will add "[encfs-corrupted]" to the name. For example:

normal (forward) mode you have one file:

• "R0RAqRPCUeoDefTmslDhg4,g"

encfs mounted directory showing it as:

• "hello.txt"

sync created a second duplicate file with syncing issues (and original file):

• "R0RAqRPCUeoDefTmslDhg4,g"
• "R0RAqRPCUeoDefTmslDhg4,g (sync conflict 09-07-2023 axet-laptop)"

encfs mounted directory showing it as:

• "hello.txt"
• "hello.txt [encfs-corrupted] (sync conflict 09-07-2023 axet-laptop)"

And same goes for --reverse and --reversewrite options. Original directory showing:

• "hello.txt"

Encfs encrypted folder:

• "R0RAqRPCUeoDefTmslDhg4,g"

After sync issues, encrypted folder will be:

• "R0RAqRPCUeoDefTmslDhg4,g"
• "R0RAqRPCUeoDefTmslDhg4,g (sync conflict 09-07-2023 axet-laptop)"

And local filesystem folder will look like:

• "hello.txt"
• "hello.txt [encfs-corrupted] (sync conflict 09-07-2023 axet-laptop)"

Patch is here (code can be cleaned up):

• https://gitlab.com/axet/homebin/-/blob/debian/cdebian-dget.d/bookworm/encfs/encfs-conflicts.patch

[Keisial]

I see the patches are now on

• https://gitlab.com/axet/homebin/-/blob/debian/dbuild.d/bookworm/encfs/encfs-cfg-xml.patch
• https://gitlab.com/axet/homebin/-/blob/debian/dbuild.d/bookworm/encfs/encfs-conflicts.patch

While I see your point in sharing the file, in case only online backup is available, others may prefer going the opposite way, and doing the encfs6 bootstrap manually on each host, with the cloud service never seeing that. That's probably . Also note that when exposing .encfs6.xml, you will need to use --require-macs on mount, to avoid the cloud service from disabling them from behind you.

I also see a possible conflict if a remote host changes the .encfs6.xml while it is mounted in which case the mounted one will probably continue using the old parameters.

I think it would make more sense under an optional flag.

Regarding the second patch, that would give out for those using --anykey. And I'm unsure whay it would do with already long (or even malicious) filenames.

[axet]

I also see a possible conflict if a remote host changes the .encfs6.xml while it is mounted in which case the mounted one will probably continue using the old parameters.

Whole point - to make a backup, in case if you lose all data from your machines (due to physical damage / lost) you can restore all data from one place without keeping encfs.xml other online/cloud storage. Since it is only for backup purpose, it never changes. Not from security perspective. Sure having --require-macs is a good option.

Regarding the second patch, that would give out for those using --anykey. And I'm unsure whay it would do with already long (or even malicious) filenames.

When sync/cloud software creates a conflict copy you unable to delete folder with conflict files since they are hidden / invisible to the user. This patch allows you to see conflict files and compare them inplace (decrypted) without manually decoding every file due to conflict.