In a while, the team decide that a week’s old file stored on agent3 is actually the one they need, put it to the folder and start agent3. File’s timestamp becomes the latest, and agent2 downloads it. It’s whose file got the latest database time.Īgent 3 is offline. So, it’s not who was the last to actually change the file.
If agent3 in any other way updated the file’s mtime, its version would be uploaded to other agents, even though nothing was edited inside the file. It’s mtime is not updated, file is not updated in database, so it downloads the newest file from agent1.
Similar file properties editor download#
Agent3 still cannot download the file as it keeps its file open. File from agent1 is uploaded to agent2 and agent3. File’s rechecked and its database time becomes newer than that on agent2. Agent1 and Agent3 cannot download it, cause their copy is still open. File won’t be uploaded - it cannot be rechecked yet. Agent1 edits the file, saves but does not close it. In this case, Agents will be syncing all the changes based on the mtime of the file - the latest is synced.Īll three agents open the file.
And finally agent3 edits file, this file is uploaded to agent2 and agent3. Then agent2 makes some changes, and this file version is uploaded to others - agent1 and agent3. Agent1 updates a file and closes it, this file is uploaded to others. We have three agents and they are working with MS Document files: when a file is opened it’s not available for synchronization. Let’s see how it all works on a few simple examples. This usually happens with, e.g., MS Office files, they’re open with exclusive access.Īnd one more condition stems from here: when exactly the app, with which file is being edited/opened, updates the mtime, whether it’s every time you click “save” while editing, or only after you close the file.Īll these conditions play their role for agent to detect and decide which file is the latest. Same way it won’t be able to decide whether or not it needs to upload its copy of file, until file’s available. Agent will not be able to accept/decline the remote file and synchronization will stall until the file’s checked. Before deciding to download a remote file, agent will compare that with its local copy. The file with the latest mtime will be synced.Īnother vital condition is the local copy of file be available for rechecking and synchronization. Otherwise it’ll be just not watching all the ongoing file changes and will just compare its local file mtime with others when it’s back online. This shall be done only if the Agent is online.
Similar file properties editor update#
If several people update the same file on different devices, Agents will still synchronize the file with the latest database timestamp. When several people update the same file on different devices If a file is updated every now and then, the behavior is pretty clear - file's mtime updates, agent detects that, verifies that mtime is newer than that on other agents and uploads the file to others.īut the situation when several people work with the same file at the same time is more common, and here it all becomes a bit more complex. In cases when you deliberately put an old file into a folder (for example, when restoring it from Archive), the database time is taken into account. In most cases it matches the mtime, but in some rare cases it doesn't, for example, if a file is moved or copied, mtime does not change, but the database time does.īasically the file with the latest database time is considered the newest and will be synced. This is the time when changes to this entry in database have been made - when agent detects the file change.
0 kommentar(er)
