[LU-20048] TCU: Trash Can and fscrypt Files and Directories

• Type: Technical task
• Resolution: Unresolved
• Priority: Medium
• Severity: 3
• Assignee: Qian Yingjin
• Reporter: Qian Yingjin

Description

When an fscrypt directory is deleted, the encryption context on the directory must be copied from the parent directory to the new pFID stub directory when it is first created, so that the encrypted filenames and contents can be accessed properly via the .Trash/ directory, as well as if an encrypted file or directory is undeleted.  The fscrypt context is partly derived from the parent directory, as well as a unique per-inode Cryptographic nonce value that ensures the encrypted data is unique, even if the same data is encrypted multiple times.

 
Users can access files that have been deleted and are located in the recycle bin via ".Trash" with read-only mode, regardless of whether the files are encrypted or not.
Since Lustre performs encryption and decryption entirely on the client side, the server stores all data in plaintext. Therefore, when filename encryption is enabled, if a file with the same name is repeatedly created and deleted within a directory, the server cannot simply append a timestamp to the end of the filename to distinguish between different versions of files with the same name. Doing so would violate the design principle that all filename encryption is performed on the client side, potentially leading to garbled characters in decrypted pathnames and possible incorrect conflicts. For the repeated deletion with the same file name within a directory with file name encryption enabled, the server can only use the policy that always keeps the oldest version of the repeated deletion file.