Calling the CfSetInSyncState() function always returns 0x80070179 "ERROR_CLOUD_FILE_NOT_IN_SYNC" if a USN parameter is specified. Regardless of the USN being passed, except for 0 or null. The correct behaviour of the CfSetInSyncState() with USN is critical for us, because we do the following sequence in our app: We read USN before the file being sent from the client to the server. Send file content from the client to the server. Mark file as in-sync by calling CfSetInSyncState() with the USN read in step 1. We can not just call CfSetInSyncState() with USN=0, because the file content may be modified on the client, between steps 2 and 3. This may result in changes being lost. We also can not block the file for modifications when sending content to server - the file must be available for modifications by applications. The issue with a sample code is described here: https://stackoverflow.com/questions/60816543/cfsetinsyncstate-does-not-behave-as-documented-cfapi Is it a cfapi bug? And when it will be fixed? @Rita Han - MSFT @Xiaopo Yang - MSFT

RitaHan almost describe all CfSetInSyncState behavior. And I would expect that the first block (setting non sync file to sync) would not fail, since the USN did not changed before the cfSetInSyncState call. (This is what currently blocks me) As CfSetInSyncState showed, the USN* parameter is InSync -Usn. So This parameter needs to be a NULL pointer for NOT_IN_SYNC . We can not just call CfSetInSyncState() with USN=0, because the file content may be modified on the client, between steps 2 and 3. This may result in changes being lost. Why does this result in changes being lost? The previous read USN is not the same as USN generated by the modified file content. Isn‘t It developer’s duty to Hydrate based on some criteria(USN)? May you need CfUpdatePlaceholder(UpdateUsn) ?

CfSetInSyncState() always fails if USN parameter is specified (cfapi)

WebDAV 106

Calling the CfSetInSyncState() function always returns 0x80070179 "ERROR_CLOUD_FILE_NOT_IN_SYNC" if a USN parameter is specified. Regardless of the USN being passed, except for 0 or null.

The correct behaviour of the CfSetInSyncState() with USN is critical for us, because we do the following sequence in our app:

We read USN before the file being sent from the client to the server.
Send file content from the client to the server.
Mark file as in-sync by calling CfSetInSyncState() with the USN read in step 1.

We can not just call CfSetInSyncState() with USN=0, because the file content may be modified on the client, between steps 2 and 3. This may result in changes being lost.

We also can not block the file for modifications when sending content to server - the file must be available for modifications by applications.

The issue with a sample code is described here: https://stackoverflow.com/questions/60816543/cfsetinsyncstate-does-not-behave-as-documented-cfapi

Is it a cfapi bug? And when it will be fixed?

@Rita Han - MSFT @Xiaopo Yang - MSFT

1 answer

Xiaopo Yang - MSFT 12,726 Reputation points Microsoft Vendor

2021-12-13T06:41:16.8+00:00

RitaHan almost describe all CfSetInSyncState behavior. And

I would expect that the first block (setting non sync file to sync) would not fail, since the USN did not changed before the cfSetInSyncState call. (This is what currently blocks me)

As CfSetInSyncState showed, the USN* parameter is InSync-Usn. So This parameter needs to be a NULL pointer for NOT_IN_SYNC.

We can not just call CfSetInSyncState() with USN=0, because the file content may be modified on the client, between steps 2 and 3. This may result in changes being lost.

Why does this result in changes being lost? The previous read USN is not the same as USN generated by the modified file content. Isn‘t It developer’s duty to Hydrate based on some criteria(USN)? May you need CfUpdatePlaceholder(UpdateUsn)?
Please sign in to rate this answer.
Coder 6 Reputation points

2021-12-14T00:18:07.813+00:00

As far as I understand Rita Han confirmed in comments on stackoverflow that there is a bug in CfSetInSyncState function:

"@lokimidgard ... For document issue I'll consult related engineer and update to you if there is any progress."
"@lokimidgard I've consulted the related engineer for helping on this issue and update to you if there is any progress."

Am I right?

We do not need to set In-sync -> not in sync. We need to se not in-sync -> in sync. If the USN is not provided there are going to be loss of data.

Xiaopo Yang - MSFT 12,726 Reputation points Microsoft Vendor

2021-12-14T01:37:33.953+00:00

I still wonder why there are going to be loss of data. CfSetInSyncState just set the in-sync state for a placeholder file. Do you think CfSetInSyncState records the newest file USN?? In other words, If CfSetInSyncState records the newest file USN, How does this result in changes being lost? We can CfHydratePlaceholder according to the previous read USN instead of the USN CfSetInSyncState return if CfSetInSyncState return.

Also try CfUpdatePlaceholder(..., CF_UPDATE_FLAG_MARK_IN_SYNC, UpdateUsn,...) instructs the platform to only perform the update if the file still has the same USN value as the one passed in and the platform marks the placeholder as in-sync upon a successful update placeholder operation.

WebDAV 106 Reputation points

2021-12-14T02:56:42.873+00:00

We have already tried CfUpdatePlaceholder() it has the same issue as CfSetInSyncState().

I still wonder why there are going to be loss of data.

The scenario with data loss is described in comments on stackoverflow:

I am aware that using an USN value of 0 will always set the sync state. But I need to check if there are not new changes. Usecase: 1. Some file got changed so it is not in sync. 2. Perform changes in cloud. 3. Set In Sync. The problem: between 2 and 3, new changes may accour. If I use 0 as USN the files would marked as in sync but there would be mssing changes. ideally: 1. Some file got changed so it is not in sync. 2. Get the USN of file 3. Perform changes in cloud. 4. Set In Sync with USN from 2. This gurates that if 4 is successfull there are no missing changes in the cloud. –
lokimidgard
Mar 24 '20 at 10:44

Xiaopo Yang - MSFT 12,726 Reputation points Microsoft Vendor

2021-12-14T03:05:42.34+00:00

Do you think the cfAPIs do the if judgment for step 4?

Mathias Eggert 0 Reputation points

2024-01-11T07:59:45.37+00:00

Yes, that is the expectation, and that is part of the documentation:

On input, UpdateUsn instructs the platform to only perform the update if the file still has the same USN value as the one passed in. This serves a similar purpose to CF_UPDATE_FLAG_VERIFY_IN_SYNC but also encompasses local metadata changes. Passing a pointer to a USN value of 0 on input is the same as passing a NULL pointer.

Otherwise, what is the way to avoid file loss? Because at the moment I can mark a file as synced, it can be dehydrated and if I mark a file as synced, which is not part of the cloud, I have a problem.

Mathias Eggert 0 Reputation points

2024-01-11T08:00:30.8933333+00:00

The big problem is, that this USN behaving does not work!

Xiaopo Yang - MSFT 12,726 Reputation points Microsoft Vendor

2024-01-12T03:11:16.4733333+00:00

Cloud Filter API is not well documented. You can open an incident at https://developer.microsoft.com/en-us/windows/support/?tabs=Contact-us so that our internal engineer can work with you closely and please choose the 'System Services Development - Cloud Filter API' for Windows SDK for this issue. In-addition, if the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

CfSetInSyncState() always fails if USN parameter is specified (cfapi)

1 answer

Your answer