Closed Owyn closed 5 years ago
Look at how others handle this: CrococryptMirror for example - it encrypts every filename into 4 symbol filename (which is in 99% times shorter than the original)
Hi @Owyn -- thank you for the repot! Encfs4win is mainly designed to just be a Windows port of the encfs project, so most of the new features and fixes are implemented upstream at encfs: https://github.com/vgough/encfs. I recommend submitting a feature request issue on that project and see what they can do.
I found a related issue that already exists on the project: https://github.com/vgough/encfs/issues/7. It might be a good place to start discussing different options for shorter filenames.
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.
Environment
Description
Even with an option to have shortest possible encrypted filenames - stream - those are still longer than originals, i mean usually twice as long, eg: test.txt - is now twice longer vKeFilGHSVaediHAJ,
that's not really the problem, the real problem comes with folders and subfolders and subfolders inside subfolders... few folders placed in each other easily reach the filesystem max-length for name, filesystem have problems with it, programs have problems with it, cloud-storage have problems with it.. just problems we have.
Expected behavior vs. actual behavior
we should have an option for kitchen-level user filename protection which is not null but won't be longer than original
something like: original: test.txt (8 symbols) output: vKeFideJ (8 symbols or shorter (just not longer))
to not put the original key in danger by this (or however filename encryption is done), another key(password?) could be used, we need SOMETHING to not have problems with name-lengths of files...