[Feature suggestion] File and Folder names encryption method

[Shaipetit]

I'm not talking about file content encryption by archiving files into .zip or .sz archives

I'm referring specifically to the method how Syncovery encrypts filenames and folder names.

In my opinion, there could be another alternative method (algorithm) to encrypt the names, because the current method results in significantly longer names than the original filenames and folder names, which leads to increasingly long path lengths.

For instance, 245 character long path after filename and folder name encryption increased to 403 characters!

As we know, Windows (including the latest version of Windows 10) has the 260 character MAX_PATH path length limit. Exceeding this limit causes various problems for built-in Windows functionalities and 3rd party applications. For instance, Windows File Explorer right mouse click - Properties dialog showing wrong file and folder count, because of inability to properly access files and folders with path lengths longer than 260 characters.

Would it be possible to include an alternative file and folder name (not content) encryption method that wouldn't generate names and paths longer than the original ones?

[superflexible]

I will consider it.

[Shaipetit]

As I've mentioned exceeding 260 character MAX_PATH path length limit causes various problems in various scenarios under Windows OS.

For instance, FileZilla FTP server also has this limitation, therefore when Syncovery tries to work with such lengthy paths, FileZilla server produces this 450 Internal error creating the directory and Syncovery produces this Error creating folder. It's possible that the server does not allow this name.

Filename and foldername encryption must not increase the length of original filenames and foldernames. It's a receipt for a disaster and infact prevents using Syncovery filename encryption with FileZilla FTP server.

Thanks for considering this feature.

[Shaipetit]

Windows OS based Wing FTP SFTP server also produces error (0000068) SSH_FXP_STATUS: Internal error when creating the directory when Syncovery tries to upload long encrypted paths.

It's clear that Syncovery filename and foldername encryption feature needs to have a different algorithm encrypting paths with names not longer than the original ones in order to be fully compatible with Windows OS MAX_PATH path length limitation.

Until such feature is implemented, it's impossible to use Syncovery's filename and foldername encryption with Windows OS based FTP or SFTP servers.

[superflexible]

That's not true, you just need to find better server software.

The Windows OS does not have this limitation. Only Windows Explorer and some other mediocre software that uses the Windows API in an obsolete way has the limit.

[rossmcm]

So what is the limitation - i.e. how long can a pathname be? (I realise I could Google this, but having the answer in this thread will be useful to other users browsing...)

[superflexible]

Windows paths can be 32767 characters long.

So far I haven't had any problem reports about long paths because this encryption feature is mainly used for cloud backup. Cloud storages do not have the 260 characters limit.

I will see if I can make the paths shorter, which means I will need to use Chinese and other Unicode characters.

[spagnola]

could you clarify more, about path length?
I had sent you also a question on this, related to help manual, but then also found this thread.

my question related to the timestamp, and the added length it caused (I realize encryption causes even longer length)

IF we are in windows, and we are using syncovery to coyp from source to destination, and the addition of timestamp and/or encryption causes the complete path to now exceed the 245/260 limit, do we lose abilty to access those files in windows, or is it htat if we use them through syncovery, they are still accessible?

what happens if I decide to take a destination folder/subfolder/etc that has some paths in it that now exceed the limit, and copy them to another drive, using windows copying mechanisms? do they get screwed up?

I personally try to keep my files/folders at a 180 to 200 char max length (I use a path length finder) (My wife creates some screwy GENEALOGY file names with some ungodly lengths, which is why i started trying to control the lengtys)

any feedback/clarification on the downsides of the longer path names, OR the RELIABILITY of them as to how we can keep from screwing them up, is appreciated

[Shaipetit]

My biggest issue with long paths on Windows OS, remains the fact that all Windows based FTP (SFTP) servers I have tried had problems with too long paths, denying Syncovery to upload files and folders with too long encrypted names.

I even contacted some of the developers of those S(FTP) servers software only to be informed that it was a Windows limitation, therefore developers would not fix it.

In general, I try to avoid long paths by using a program called TreeSize:
https://www.jam-software.com/treesize/s ... aths.shtml

By the way, if anyone knows Windows OS based S(FTP) server software that has no problems handling long paths, please let me know.

[spagnola]

i use LongPathFinder.exe, and
LongFile.exe (http://www.dcsoft.com, as of last upload)
also Bulk REname, latest version has ability to see FILE and PATH length