Local Storage

The unnamed data attribute of an NTFS file has the information being tracked by NTFS that is needed to manage the data. The modification time, logical size, physical size, and access time of the file are all kept relative to the unnamed data attribute. The modification time and logical file size are never changed for the file even when it is a placeholder.

First Read, Write, and Memory Map

The file is recalled if necessary on the first read, write, or memory map request. If the data is in remote storage but is not in the library, the recall does not succeed. Automatic recall of data that is not in the library is not available and fails with the message STATUS_FILE_IS_OFFLINE. The administrator needs to manually insert the media into the library and then try the recall again.

If a request is made against a premigrated file, it is not affected by Remote Storage. The data for the file exists locally on the NTFS volume and is accessed normally.

The client making the request on the server might time out. Client computers have their own configured time-out which is independent of Remote Storage, and if recalling the data takes longer than the time-out, the input/output request fails on the client. In Windows 2000, the time-out for accessing off-line Remote Storage files is 15 minutes.

Note

Changing attributes or ACLs or named streams in a file does not recall the file.

NTFS "File Open"

By default, when a placeholder is opened on an NTFS volume, the data is copied directly from remote storage to local storage and the file is considered a premigrated file. The last access time of the file is changed. Specific error cases arise because of the state of the system or the location of the data in remote storage. When the data cannot be brought back to local storage, the open request always fails with the message STATUS_FILE_IS_OFFLINE.

The FILE_FLAG_OPEN_NO_RECALL flag is honored if the file is opened for read access only, or if the open fails.

If the open request is made with the FILE_FLAG_OPEN_NO_RECALL flag the data is recalled at read time, cached, and placed directly into the application's read buffer. This allows backup systems to get an image of the file that appears (and restores) as a premigrated file but that was not recalled by the backup application.

Note

The migrated data appears only briefly and is not actually copied to local disk storage.

Runaway Recall Detection and Prevention

Runaway recalls can be prevented by specifying that no more than a certain number of files can be recalled by a user from a volume in an hour. This is an administrator-defined setting, both in terms of enabling or disabling the feature, and in specifying the number of recall requests that are handled in a particular period of time.

Administrators can select exemption from any recall limit.

Deletion of a Premigrated File or Placeholder

No action is taken upon the deletion of a placeholder or premigrated file. It is not possible to synchronously determine when a file is going to be deleted.

Renaming, Moving, or Copying Placeholders and Premigrated Files

Files cannot be renamed across volume boundaries. Placeholders and premigrated files can be renamed only on the same volume. Renaming a file does not cause the data in remote storage to be recalled. Truncation and recall of these files are not affected.

Copying or moving placeholders between volumes causes the data to be recalled and the entire file, including all migrated data, is copied. At the end of a move operation the original placeholder file is deleted. Copying a file has the same behavior within a volume or across volumes. Moving placeholders on the same volume is a rename operation.

A placeholder can be moved to another volume within the same system by using Backup to back up and restore the placeholder to another volume. In this case, the moved placeholder points to remote storage and is valid to initiate a recall. A user-defined action to validate placeholders corrects any potential inconsistencies between the placeholder and remote storage. Even without the validation of a placeholder, opening the moved placeholder recalls the correct data; however, a volume decommission does not work properly.

Table 2.11 summarizes the results of the specific actions when the destination of the action is the same or a different volume.

Table 2.11 Results of Premigrated File Actions

Action	Destination Same Volume	Destination Different Volume
Copy File	Recall	Recall
Cut File	Recall and delete original	Recall and delete original
Move File	No Recall (is a Rename)	Recall and delete original
Rename File	No Recall	N/A

Volume Decommission

When a managed volume is decommissioned, the physical volume is not accessible. All information needed to decommission the volume is already known. Any data associated with the volume that is in remote storage is treated as available during space reclamation.

If placeholders are moved between volumes, the placeholders must be validated so that correct volume information is known about the placeholders. If the placeholders have not been validated, the volume decommissioning can cause incorrect data within remote storage to be treated as available during space reclamation. For more information about validating volumes, see "Local Storage Management" earlier in this chapter.

Restoring Placeholders from Backup and Disconnected Placeholders

A primary storage backup application, such as Backup, protects placeholders. If the placeholder is deleted, lost, or destroyed the only recourse is to retrieve a copy from the backup media. This is the same mechanism that must be used if any other file on the volume is deleted, lost, or destroyed.

The data in remote storage is accessible only through a placeholder. If the placeholder is deleted, that data is inaccessible. If a placeholder is restored from backup, the placeholder is reconnected to that data.

Disconnected placeholders are placeholders whose file contents have been removed from remote storage. These placeholders might have been restored from backup after the space in remote storage was reclaimed or the data within remote storage might be physically unavailable because of media failures. Disconnected placeholders do not point to valid locations in remote storage and are cleaned up by validating placeholders. If the placeholders are disconnected, they are removed from the system to synchronize the remaining placeholders with remote storage.

Interaction with other Reparse Point Types

Volume mount points and symbolic links cannot be changed into placeholders. The system explicitly ignores these types of files.

Any file system scan that encounters a mount point or symbolic link does not follow the link: physical volume space is the scarce resource and mount points and symbolic links are virtual concepts that extend the directory view.

Placeholders Binding to a Specific Remote Storage

Placeholders identify the specific remote storage system which contains the managed data, tying a placeholder to a specific Remote Storage Engine. Placeholders cannot be moved between multiple remote storage systems.

Windows 2000 Security Integration

Remote Storage supports NTFS security features. Remote Storage only recalls files if the user has valid access to a placeholder. A placeholder is identified as a special remote storage reparse point. The security of the placeholder is determined by the security of the reparse point mechanism.

Administrators and regular users go through normal Windows 2000 user security checks. The Remote Storage Administrative user interface uses Windows 2000 permissions to grant or deny access to the user interface. Only user accounts in the Administrators group are allowed access to the user interface functions.

File Collocation

Files are grouped together by their volume and by the time that they were originally premigrated. The files remain grouped during all remote storage operations. No other grouping of files is supported.

Replication

Files that are being replicated can be excluded from the Manage Files action by the administrator using the file selection criteria.

© 1985-2000 Microsoft Corporation. All rights reserved.