Browse Prior Art Database

Method of Determining Local File System Changes When Synchronizing Files Within a Collaborative Remote Repository

IP.com Disclosure Number: IPCOM000236914D
Publication Date: 2014-May-22
Document File: 4 page(s) / 84K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to prevent false reported deletes of document files in order to prevent loss of server metadata as well as improve the tracking of renames and the creation of new files when needed. This better accommodates file saving and tracking in a collaborative environment in which files are shared.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 29% of the total text.

Page 01 of 4

Method of Determining Local File System Changes When Synchronizing Files Within a Collaborative Remote Repository

The problem solved by this disclosure is one of being able to accurately follow and identify all changes to files in a local monitored directory. These files are also 'linked' to remote repository files with server metadata. While this seems like something that is very trivial, there are applications and user behaviors that can cause this monitoring to conclude inaccurate states of files and potentially lose the link between the local file and repository file.

One example of an application with unexpected results involves a Microsoft* Windows machine that uses Microsoft Word as an editor. Word's newer versions of the editor can enable AutoSave features which results in the editor using multiple files during an edit session. The behavior of Word can be described as a main document (main.doc) that is open and locked while a secondary temporary/hidden document (~main.doc) is also opened and locked. During Edit sessions, upon saving, the main.doc is deleted and ~main.doc is renamed to main.doc, and a new temporary ~main.doc is created. This can cause unexpected results when monitoring this file for changes. One possible point of confusion this behavior causes is that the original file can be reported as a deleted file and the newly renamed file can be reported as a created file. If this change was handled as two separate events (e.g., delete, create), the original file (with associated meta-data)

would be deleted and a new file would be created. This is not the behavior expected by the end user.

One example of a user behavior with unexpected results is when a user unintentionally deletes a file in the monitored directory on a Microsoft Windows machine and then restores the deleted file from the Recycle Bin. Most current monitoring systems would see that behavior as a deleted file and a created file,

when it should be seen as a delete and restore. Again, the result is to delete the original file and create a new file - even though these files are affectively the same. This results in loss of meta-data with the associated server copy of the file.

Both of these scenarios seem relatively harmless when at the end of the scenario, the user ends up with the data/content from the file being monitored and it gets pushed to a remote repository. However, when users begin to introduce

collaborative information such as sharing, recommendations, likes, pinning, comments, versions and other specific file metadata tied that that file, the act of a delete can be severely catastrophic for the user since a create will not carry any of that information over.

The novel contribution is a method to not only prevent false reported deletes in order to prevent loss of server metadata, but also improve the tracking of renames and the creation of new files when needed.

The method maintains multiple snapshots of the documents in the monitored directo...