Matthieu, Please find the answer to question 2 as follows.
=== 2 === Given DC1 & DC2. File is on both systems. From DC1… DC1 sends remote Co Command to DC2 to notify of a change… DC2 accepts the change (by responding with “Send Stage” …what would prevents the file from being modified by DC2 while DC1 is syncing? Answer: If an application tries to modify the file on DC2 while another version is being replicated from DC1, the staging file will be downloaded from DC1 but the installation could fail on DC2 (until the file is closed) due to frsFlags and FileVersionNumber. FRS cannot install a file at the destination location if encounters a sharing violation. If there exists a newly created version of the file, the conflict is resolved as specified in MS-FRS1. The processing rules, documented in MS-FRS1 3.3.4.4.6, apply to the scenario you described as follows. Event Time Delta is the difference between the times of the two change orders. The two change orders are the remote one and the one created due to the change made by the application which modified the file on DC2. 3.3.4.4.6 COMM_COMMAND Is CMD_REMOTE_CO <Excerpt> If identically named files are created or modified on two or more replica members, the downstream partner MUST use a "last writer wins" rule; this means that the most recently created or modified version of a file becomes the version that is replicated to the other replica members. All change orders have event times in Coordinated Universal Time (UTC). These event times are used for comparison to the IDTable: Event Time delta > 30 minutes: Last writer wins. Event Time delta <= 30 minutes: Highest version wins (that is, most prolific writer wins). If both the event times and versions match, the file with a larger size wins. If the file size also matches, the change order with a larger Originator GUID wins. </ Excerpt> Regards, Edgar -----Original Message----- From: Edgar Olougouna Sent: Thursday, October 13, 2011 3:44 PM To: '[email protected]' Cc: [email protected]; [email protected] Subject: RE: Two new MS-FRS1 issues from Matthieu Patou re "Locking" Matthieu, The CMD_RETRY_FETCH and ERROR_SHARING_VIOLATION error conditions are already documented in MS-FRS1 3.3.4.4.7. Also, what I meant by “blocked” is that the file is downloaded but will not be installed, and as long the file is not recorded in the IDTable (Sections 3.1.1.5 IDTable), the newly downloaded version will not propagate to downstream partners because no change orders will be sent. 3.3.4.4.7 COMM_COMMAND Is CMD_SEND_STAGE http://msdn.microsoft.com/en-us/library/dd340857(v=PROT.13).aspx <Excerpt> The downstream partner will receive the CMD_ABORT_FETCH (see section 3.3.4.4.10) or CMD_RETRY_FETCH (see section 3.3.4.4.11) packet if the upstream partner is unable to handle the CMD_SEND_STAGE packet for any of the following reasons. When the upstream partner receives the CMD_SEND_STAGE request then the out connection MUST be in JOINED state. If the connection is not in JOINED state then server MUST send CMD_RETRY_FETCH back to downstream partner. The downstream partner MUST perform the initial sync and then send a CMD_SEND_STAGE to the upstream partner. If the upstream partner is unable to access the staging file due to ERROR_SHARING_VIOLATION then the upstream partner MUST send a CMD_RETRY_FETCH back to the downstream partner. If the staging file is missing then the upstream partner MUST try to generate the missing staging file. If the upstream partner is unable to create a missing staging file with ERROR_DISK_FULL then the upstream partner MUST send CMD_RETRY_FETCH to the downstream partner. ERROR_DISK_FULL is also generated when the staging quota is reached for the replica set; the error goes away when staging quota is increased manually or staging cleanup is done by the upstream partner. If the upstream partner fails to create the staging file because of any other failure (such as an ACCESS_DENIED error) then the upstream partner MUST send a CMD_ABORT_FETCH to the downstream partner. If the upstream partner is unable to fetch the staging file because it has already been deleted then the upstream partner MUST send a CMD_RETRY_FETCH to the downstream partner, which will cause the file to be recreated on the next CMD_SEND_STAGE request from the downstream partner. If the upstream partner is unable to read the file due to file corruption then the upstream partner MUST delete the corrupted file and send CMD_RETRY_FETCH to the downstream partner, which will cause the file to be recreated on the next CMD_SEND_STAGE request from the downstream partner. </Excerpt> Thanks, Edgar -----Original Message----- From: Matthieu Patou [mailto:[email protected]] Sent: Thursday, October 13, 2011 6:05 AM To: Edgar Olougouna Cc: [email protected]; [email protected] Subject: Re: Two new MS-FRS1 issues from Matthieu Patou re "Locking" On 12/10/2011 22:52, Edgar Olougouna wrote: > Matthieu, > > Please find the answer to question 1 as follows. I will provide the answer to > question 2 soon. > > === 1 === > > What happens at DC2 if a third system tries to lock the file between the time > that DC2 notified DC1 "Accept the change from DC1) and when and the file has > been downloaded (staged) and install it in the destination directory? > > Answer: > > The FRS upstream partner holds an exclusive oplock on the source file while > *generating the staging file*. Once the staging file has been created, it > releases the oplock handle. > Any further change to the source file will be reflected in subsequent change > orders. > That being said, it is possible that FRS cannot generate the staging file to > be replicated if it encountered a sharing violation. For example, if another > entity has opened the source file with 0 as the sharing mode parameter, or > has opened the file with an exclusive lock, then FRS will not be able to open > it for read access and will encounter a sharing violation, and as a result > will not be able to generate the staging file. Ok if so is there anything returned to the downstream partner? like CMD_RETRY_FETCH ? I think paragraph 3.3.4.4.7 should be updated to add information about locking issue. > On the downstream partner, if the target file - to be replaced - on the > destination was opened, then FRS would not override the "old" file and > replication would be blocked, unless the "install override" feature is > enabled (frsFlags). The frsFlags attribute is documented in MS-FRS1 2.3.1.2 > NTFRS Replica Set Object. Can you explain the "blocked" meaning in this case, from what I've seen it seems that other file will be replicated just this one is hold in the staging area and most probably this member will not propagated this change to other members. > Additional references: > FRS Encounters "ERROR_SHARING_VIOLATION" Errors When It Tries to > Replicate Data That Is Still in Use > http://support.microsoft.com/kb/822300 > How to configure the File Replication Service to allow fewer sharing > violations that block replication > http://support.microsoft.com/kb/816493 > > Regards, > Edgar > > -----Original Message----- > From: Edgar Olougouna > Sent: Tuesday, September 20, 2011 3:52 PM > To: '[email protected]'; [email protected]; [email protected] > Subject: RE: Two new MS-FRS1 issues from Matthieu Patou re "Locking" > > [Dochelp to bcc] > > Thanks Matthieu for this input, I will investigate and follow up. > > Regards, > Edgar > > -----Original Message----- > From: Matthieu Patou [mailto:[email protected]] > Sent: Tuesday, September 20, 2011 3:48 PM > To: Edgar Olougouna; Interoperability Documentation Help; > [email protected]; [email protected] > Subject: Re: Two new MS-FRS1 issues from Matthieu Patou re "Locking" > > Hello Edgar, > > Initial testing seems to indicate that when trying to install a staged file > FRS obey to lock. It might help you to orientate your work. > > Matthieu. > On 20/09/2011 13:45, Edgar Olougouna wrote: >> [Bcc Bryan] >> >> Matthieu, >> >> I am taking care of these questions. I will update you as soon as I have >> news. >> >> Thanks, >> Edgar >> >> From: Bryan Burgin >> Sent: Monday, September 19, 2011 5:24 PM >> To: [email protected] >> Subject: RE: Two new MS-FRS1 issues from Matthieu Patou re "Locking" >> >> [Protocol team on bcc] >> >> Matthieu, >> >> Below are the case numbers for each of these issues. >> Someone from the team will contact you soon. >> >> 111091980340447 >> 111091980132344 >> >> B. >> >> From: Bryan Burgin >> Sent: Monday, September 19, 2011 1:17 PM >> >> Subject: Two new MS-FRS1 issues from Matthieu Patou re "Locking" >> >> >> >> [email protected]<mailto:[email protected]> >> >> === 1 === >> >> What happens at DC2 if a third system tries to lock the file between the >> time that DC2 notified DC1 "Accept the change from DC1) and when and the >> file has been downloaded (staged) and install it in the destination >> directory? >> >> === 2 === >> >> Locking... >> >> Given DC1& DC2. File is on both systems. From DC1... >> >> DC1 sends remote Co Command to DC2 to notify of a change... >> >> DC2 accepts the change (by responding with "Send Stage" >> >> ...what would prevents the file from being modified by DC2 while DC1 is >> syncing? >> >> > > -- > Matthieu Patou > Samba Team > http://samba.org > > -- Matthieu Patou Samba Team http://samba.org _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
