[BUG] Crypt overlay: editing outside the Overlays Path (Mixed mode)

[EhudKirsh]

Describe the bug
Uploading a file to a folder with an unencrypted name while ‘🔒 RCLONE CRYPT’ is On (appears blue) creates a new folder with that name,
but encrypted.

Steps To Reproduce

1. Set up a Crypt wrapper on a profile and connect to it.
2. Click on ‘🔒 RCLONE CRYPT’ to turn it Off/grey.
3. Right-click in the remote panel and create a new folder. Let’s name it "Crypt".
4. Enter this new folder.
5. Click on the ‘🔒 RCLONE CRYPT’ button to turn it On so it appears blue.
6. Drag and drop some file from the local panel to the new folder.
   The folder will appear empty, even though the ‘📤 Transfer Queue’ and ‘📜 Log’ seem successful.
7. Go back to the root directory and click on ‘🔒 RCLONE CRYPT’ to turn it grey/Off, or go to the cloud drive’s website.
   You’ll see that a new folder was created, with the name “Crypt”, but encrypted, and this is where the encrypted files were uploaded to.

Expected behavior
Be able to encrypt and upload files to a folder that doesn’t have an encrypted name, and not create a new folder when attempting to do so.

Environment:

• OS: Windows 10
• AeroFTP Version: v4.1.2

Additional context
I also tested it the other way around and am happy to confirm that there’s no opposite issue as well of a folder with an encrypted name creating a new folder with its name decrypted when uploading a file when Crypt is off. This would make it a privacy-critical bug by leaking secret folder names.

[axpnet]

Thanks for the precise repro, I reproduced it end to end and confirmed the root cause.

With the crypt overlay on, AeroFTP works out the on-wire location by encrypting the whole current path. A folder you created while the overlay was off has a plaintext name with no encrypted counterpart, so encrypting that name points at a different, new encrypted folder. That is why the file lands there and the folder you are standing in looks empty even though the log says success. I also confirmed your observation that the reverse direction does not leak plaintext folder names, so there is no privacy regression here.

There is one design wrinkle I want your take on before I pick the fix. With the overlay on, a folder whose name is not valid ciphertext is currently treated as foreign and hidden from the decrypted listing. That is the same mechanism that stops a foreign vault from leaking undecryptable rows, and it is also behind the empty listings you saw in #386. So "upload into a plaintext-named folder" is genuinely ambiguous today: that folder is not part of the encrypted view in the first place.

I see two coherent ways to fix it and I would like your preference:

1. Strict. The overlay refuses to write into a location that is not part of the encrypted view, with a clear message, instead of silently creating a second folder. Turning the overlay on also re-reads the current folder so you are never left standing inside a hidden one. This is predictable and safe, but it does not let you mix a plaintext folder name with encrypted files: to work there you would keep the overlay off, or move into a proper encrypted folder.

2. Mixed. The overlay keeps the current on-wire folder as it is and encrypts only the new file, so the file lands in the plaintext-named folder you are in and no second folder is created. To make that consistent the listing would also show plaintext-named folders as raw instead of hiding them. This matches your expectation of uploading encrypted files into a folder that has a plaintext name, but it is essentially the Overlays Remote Path scoping idea from Quick Connect redesign for multi-protocol connectors #369, so it is a larger change that I would rather land together with that.

My leaning is option 1 for the next release as the safe, self-consistent fix that removes the silent second folder immediately, with option 2 folded into the #369 Overlays Remote Path work. Either way the same root also fixes the crypt cd into a decrypted folder you flagged separately. Targeting v4.1.3. Which of the two matches what you had in mind?

[EhudKirsh]

Which of the two matches what you had in mind?

I'm not sure if I have a preference.

[axpnet]

Fixed on main, shipping in v4.1.3. Since you did not have a strong preference, I went with option 1 (strict): with the overlay on, uploading into a plaintext-named folder that was created while the overlay was off is now refused with a clear message instead of silently creating a second encrypted folder, and arming the overlay re-anchors you out of a hidden plaintext folder to a valid encrypted location (while keeping you in place inside a genuine encrypted subfolder, so toggling on/off to compare encrypted vs decrypted no longer bounces you to the root). The same root also fixes the crypt cd into a decrypted folder you flagged. Option 2 (encrypted files inside a plaintext-named folder, with those folders shown as raw) is the Overlays Remote Path scoping from #369, so it lands with that larger change rather than half-done here. Tracked in #388.

[EhudKirsh]

I retested this in v4.1.4. I now understand what you meant by Strict. Going through the Steps To Reproduce that I listed, attempting step 5 now changes the directory back to the Remote Path or the Overlays Remote Path. In other words, it's less flexible, because now AeroFTP doesn't allow Crypt to be On inside a subfolder with an unencrypted name that's inside a folder with an encrypted name.
Perhaps there's never a need for this either, though.