Different file storages support different capabilities, which may lead to potential data loss when moving a file or folder from a feature-rich storage into another one with fewer capabilities. Examples of such extended capabilities could be multiple versions of a file, permissions or shares bound to the file/folder, or additional metadata such as notes or categories of files.

By default, such potential data loss will be handled by a 2-step approach. Whenever a file or folder is moved from one storage into another, a check is performed indicating whether the target storage supports all required capabilities in order to store the source data. If everything can be saved without further conflicts, the move operation is actually performed. Otherwise, the move operation is cancelled, and warnings about all detected problems are sent to the client.

The user then has the chance to review the problematic files and/or folders. If the reported problems are acceptable, the client may repeat the request and set the parameter ignoreWarnings to true in order to force the execution of the move operation, independantly of possible loss of extended data.

The following methods will support an additional boolean parameter named ignoreWarnings:

- PUT /ajax/infostore?action=update ( http://oxpedia.org/wiki/index.php?title=HTTP_API#Update_an_infoitem_via_PU T )
- PUT /ajax/folders?action=update ( http://oxpedia.org/wiki/index.php?title=HTTP_API#Update_a_folder )

When performing one of the above requests, the client should also be prepared to handle a special error code that is returned whenever there is potential data loss and the ignoreWarnings parameter was not set or set to false.

For the update action of the folders module, the error code is FLD-1038. For the update method in the infostore module, the error code is FILE_STORAGE-0045. In case of such an error response, the warnings array of the JSON object contains detailled information about each detected problem, along with a readable error message that the client should display to the user. Doing so, an additional option should be provided for the user to perform the action anyway, which then would trigger the same request again with ignoreWarnings set to true.

The following shows an example of such an response of the update action in the infostore module:

timestamp: 0,
error: The