Protected file against opening in windows causes corruption of encrypted data structure!!!

[danielborkovec]

Problem by files with: "This file came from another computer and might be blocked to help protect this computer"

win10-64bit - Configuration of cppcryptfs: - File Names: AES256-EME - long file names: yes - Long name max: 62

Some os-windows are set up so that files downloaded from the internet or email attachments are blocked from being opened. (in Home-Edition not possible to change it??) In file properties:
"This file came from another computer and might be blocked to help protect this computer" Unblock it checkbox.

If this is not manually unlocked for each file, it causes an error to be reported when the file is copied to the encrypted disk: unprotect the file for writing.
However, if I do this, the file can no longer be possible to copie and it reports an file access error (on target site). On investigation, I found that on the first write attempt, the file remained on the crypted disk (two files - one the file itself, the other its long name)

• gocryptfs.longname.ktzOershBEYfDtfgs5pxpXn6Qn7Z2gbSOJRv2mkVp0
• gocryptfs.longname.ktzOershBEYfDtfgs5pxpXn6Qn7Z2gbSOJRv2mkVp0.name

but is not shown on the encrypted mounted disk (p:/)

Therefore, it cannot be copied to the same place again (only if it is renamed). At the same time, however, the directory in which such a file is located cannot be deleted either - because it is not empty, but the computer cannot delete it from the attached disk p:/ if it does not "see" it

This is a big problem because the data structure of encrypted files is corrupted!!! this lost file is practically untraceable due to its encrypted name

This file protection does not matter and there is no copy error reported if the configuration is used
File Names: plain text
normal file protection set by the user to "read-only" also does not cause this problem

[kzshantonu]

@danielborkovec meanwhile use this to batch-remove stream information from all files recursively inside a directory.