Critical Bug - File Loss When Creating and Deleting Certain Directories

[touch4]

I have mounted two disks under /olares/share, named disk1 and disk2. These mount points are recognized and accessed by the Olares system. When creating any directory whose name starts with "Application" under either of these mount points, the directory is automatically converted into a namespace (pvc-*) directory.

When this auto-converted directory is manually deleted, all sibling directories and files at the same level are also deleted, regardless of their names or contents. This is a critical flaw—the data loss it causes is unacceptable and could have severe consequences in production environments.

Steps to Reproduce:

1. Go to disk1, and create a test directory named ABCD.
2. Create another directory named ApplicationABCD.
3. Observe that ApplicationABCD is automatically renamed or converted into a directory like pvc-***.
   
4. Manually delete the pvc-*** directory.
5. Check and find that the sibling ABCD directory has also been deleted.
   

This issue results in unexpected and irreversible data loss. It is extremely dangerous and needs to be addressed immediately. No system or user should bear the risk of such unpredictable behavior.

Environment:

• Olares version: 1.11.7
• OS: Ubuntu 22.04
• Arch: AMD64

[pengpeng]

@touch4 Thank you for your patience.

This is a serious bug. I have reproduced it on version 1.11.7.
This is because Files handles multiple different types of file systems at the same time, and there is an error in the path parsing. (We guess that because the directory name starts with Application, it is mistakenly identified as another file system)

In the new version 1.12.0 (not yet released), we have completely rewritten this part of the logic. I just tested it and there is no such problem.

We may need to spend some time looking at the code of 1.11.7 to specifically locate how the problem occurs.

[touch4]

@touch4 Thank you for your patience.

This is a serious bug. I have reproduced it on version 1.11.7. This is because Files handles multiple different types of file systems at the same time, and there is an error in the path parsing. (We guess that because the directory name starts with Application, it is mistakenly identified as another file system)

In the new version 1.12.0 (not yet released), we have completely rewritten this part of the logic. I just tested it and there is no such problem.

We may need to spend some time looking at the code of 1.11.7 to specifically locate how the problem occurs.

Thank you for your prompt response, and many thanks to the team for your efforts in developing version 1.12.0. I'm looking forward to its release!