Browse Prior Art Database

Method for Remote File Editing with Caching and Conflict Handling

IP.com Disclosure Number: IPCOM000011463D
Original Publication Date: 2003-Feb-21
Included in the Prior Art Database: 2003-Feb-21
Document File: 7 page(s) / 111K

Publishing Venue

IBM

Abstract

Disclosed is a method for enabling a user to seamlessly edit remote files using caching. This method allows cached copies of remote files to reside on a user workstation such that changes made to the cached files may automatically be pushed back to a remote host both during and between sessions. This remote editing framework facilitates the editing of remote files offline and across sessions by identifying conflicts and assisting the user in resolving those conflicts. Metadata is stored locally about each cached file enabling the framework to determine the corresponding remote file and whether any conflict exists between them. Having the ability to resolve conflicts using this metadata allows remote editing of files without file locking.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 22% of the total text.

Page 1 of 7

Method for Remote File Editing with Caching and Conflict Handling

   The are many situations where a computer user needs to edit files that do not reside on his/her computer but rather on some remote server. The steps a user needs to take to edit such a file are as follows: download the remote file to a local temp file


1.


2.


3.


4.


5.


6.

When a user needs to do this frequently, it is useful to automate those steps. The process can be made seamless so that the experience of editing remote files is no different from the much more familiar experience of editing local files. A remote editing framework can facilitate these steps by providing a user interface for allowing the user to choose which remote files to edit much like a typical local file browser will do. When a user chooses to open a remote file, the a framework downloads that file to some temporary location and opens an editor against the local copy. A user may then edit the file just as he/she would a local file. Such a framework needs to have some kind of resource change event listener to determine when the user saves the temp file. When a save event occurs, the framework's event listener determines which temp file has changed and, via some mapping, determines the associated remote file. The saved temp file gets uploaded to it's original remote location, updating the contents of the remote file with the user's changes. After the user is finished working with the temp file, it is erased.

There are potential problems that may occur in this scenario. The remote file may change independently of the temp file before the temp file gets saved. The easiest way to prevent that problem from occurring is to lock the remote file when it is downloaded until the user is finished editing it. However, locking, in itself, may lead to other problems. First of all, it's possible that someone with the right authority may unlock the remote file after it is locked. So, although somewhat safer, the original problem may still exist even if a file is locked. Another problem with the locking approach is that there may be cases where the remote file doesn't get unlocked. A user may download and lock the remote file but never finishing working with the temp file. A user may get disconnected from the network, and, as a result, the remote file will remain locked for at least that duration. If the user closes the editor while disconnected, he/she, not only loses his/her work, but the remote file lock still remains.

The key obstacle in trying to treat remote files like local files is that a user can become disconnected from remote files. If a user becomes disconnected from the remote system, and therefore disconnected from his/her files, then he/she is unable to edit those files. For example, a user brings a laptop into work, connects to a corporate network, works with files and then, later that evening, disconnects from the network (and thus the files) before boarding an airplane for a business trip. Because...