mirror of
https://github.com/rclone/rclone.git
synced 2026-10-04 11:46:08 -04:00
TowyTowy
66dba8239f
The --b2-versions support added in3fe2aaf96strips a version string from the last segment of a path before encrypting it, so that the plain text version suffixes which the underlying backend appends to encrypted file leaf names can be handled. EncryptDirName and DecryptDirName share that code, so the last segment of a *directory* name was version stripped too. Only file leaf names are ever given a version string by the backend - a directory gets a version-string-like name from the user, and such a name is encrypted verbatim when it appears as the parent of a file name, so the same directory ended up with two different encryptions. Before this change, with a directory whose name matches rclone's version format, eg dir-v2001-02-03-040506-123: rclone copy file.txt crypt:dir-v2001-02-03-040506-123/ rclone ls crypt:dir-v2001-02-03-040506-123 # => "directory not found" - the file is invisible to listings rclone mkdir crypt:dir-v2001-02-03-040506-123 # => creates a second directory with the same decrypted name After this change EncryptDirName and DecryptDirName encrypt directory names verbatim, so a directory encrypts the same way whether it is named on its own or as the parent of a file. Version strings are only added to file names by the underlying backend, so --b2-versions is unaffected and the existing version tests are untouched. A directory which was created by the old EncryptDirName will no longer decrypt and will be reported as undecryptable in listings. Such directories were already unusable - anything copied into one was written to a different encrypted directory - so nothing which worked before is broken by this. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> (cherry picked from commit67b184d6e7)