Moving A Workspace
Recently, a customer reported that SnapshotCM "hung", after
migrating their workspaces to a solid state drive. Investigation showed that
the file system clone failed to copy the SnapshotCM's workspace cache files.
The cache files, one per snapshot mount, store workspace state that allows
SnapshotCM to efficiently interact with the workspace. When this information is
missing, SnapshotCM automatically recreates it, which can be time-consuming as
it involves checking out and comparing each file in the workspace with the
corresponding file in the snapshot. Especially for very large workspaces, this
can appear as a hang. If you run into this, the easiest solution might be
simply to be patient. But if you have several large workspaces, read on for
SnapshotCM cache files are stored, one per mount point, as
an alternate data stream (ADS) on each mount directory when operating on a
Windows NTFS file system. (On non-NTFS file systems, they are stored in the
file .cache.SnapshotCM in each mount directory.) Since ADS files are normally
invisible, it's easy to understand why copy or clone software might fail to
copy them. In fact, Windows makes it pretty hard to see them. This is good in
that it greatly reduces the likelihood that the cache files will be
inadvertently removed or corrupted. And they are not "in the way." But when you
want them, it takes special effort to see or copy them.
ADS files are not visible from Windows Explorer. You need to
use the command-line (or a third-party utility) to see them. So fire up a CMD
window and run dir /R to see them. The /R option lists ADS
files, which show up with file names containing three, colon separated
components. For the SnapshotCM cache, they look like
mountdir:SnapshotCM:$DATA where mountdir is the name of a
mount point directory in the workspace. Note if mountdir is a just one
character, it must be prefixed with another directory to distinguish it from a
drive specification (.\M:SnapshotCM works). The rest of the name
identifies this as a data stream named SnapshotCM.
To view the contents of a SnapshotCM cache file, the easiest
option is to run wdump -c [dir] where dir is any directory in the
mount whose cache is to be displayed. wdump will then write the cache file to
stdout. Alternatively, the more command can display the contents of an
ADS stream. In our example, enter more < mountdir:SnapshotCM. Most
Windows commands do not understand ADS files or the illustrated ADS syntax.
Windows tools, such as Windows Explorer and xcopy, correctly
copy ADS data, even though Windows Explorer can't display ADS items. The target
file system also must be NTFS to preserve the ADS. Disk cloning tools,
including backup and restore solutions, may not copy/backup/restore ADS items
correctly, leading to the loss of the SnapshotCM cache. If the ADS is not
copied, or not supported in the target file system, or you are copying from a
non-NTFS system to an NTFS system, then use the more command to copy
the cache files from the old workspace to the new. For example: more <
oldmountdir:SnapshotCM > newmountdir\.cache.SnapshotCM. Any such
copying should occur before invoking any SnapshotCM tool on the copy.
And once the cache is initialized, we strongly recommend that you leave it
For Windows NTFS to Windows NTFS copying or moving of
workspaces: Use Windows Explorer or xcopy.
For Windows NTFS to non-NTFS: Before removing the original
location, extract the ADS cache files into regular files. Once the copy/move is
completed and before using SnapshotCM, copy the saved cache files into
.cache.SnapshotCM in the corresponding mount directory.
For Non-NTFS to Windows NTFS: Copy or move the data, then
before using SnapshotCM, copy the .cache.SnapshotCM files into the ADS stream
on the mount directory.
For non-NTFS to non-NTFS (all non-Windows platforms): Copy
or move the hierarchy. The .cache.SnapshotCM files should be moved or copied
appropriately as part of the hierarchy.
For further study, we suggest
Data Streams: Out of the Shadows and into the Light.