[cfapi] Issue regarding modifying the status of folders #624
Unanswered
zhengguanjie
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I would like to inquire about the current usage of this library, cfapi
When creating a directory, CfCreatePlaceholders: the directory status is set to MARK_IN_SYNC, and DISABLE_ON_DEMAND_POPULATION is enabled. If the directory exists locally, it is converted through CfConvertToPlaceholder, and the tag is marked with CF_CONVERT_FLAG_MARK_IN_SYNC.
Phenomenon:
In a folder with relatively few sub-files, the folder can automatically aggregate and display based on the files inside. If there are spinning circles inside, the folder will display spinning circles; if there are clouds, it will display clouds; if all are checked, it will display a checkmark. However, when there are many files inside, I tested with 1000 files for verification, and there was a problem with the folder aggregation. It seems that it can only aggregate the status of the front part of the files, and the back part cannot be aggregated, which is a bit like exceeding the cache. For example, when downloading, even if the actual folder has not been fully downloaded, perhaps only 300+ files have been downloaded, the outer folder will automatically aggregate to a checked status. The same applies to uploading. When in a static state, if I create a new file or perform other operations on files that are relatively later in the sequence, there will be issues with the folder's aggregation status, and only the front part can be aggregated
Question:
I would like to know how to handle the status of folders, especially in the case of large folders. It's impossible for us to control it explicitly. Wouldn't that be very cumbersome? We would have to change the status every time a file is moved, and once we set not_in_sync, we would have to explicitly control all subsequent statuses. This shouldn't be the way to handle it. I would like to inquire about how to handle the status of such folders?
All reactions