Each file system has its own unique characteristics.
However, moving objects to a different file system might mean losing the advantages
of the file system in which the objects are currently stored. You might want
to move objects from one file system to another to take advantage of those
characteristics.
Before moving objects to another file system, you should be familiar
with the file systems on the integrated file system and their characteristics.
You should also consider the following situation:
- Are you using applications that use advantages of the file system that
the objects are currently in?
Some file systems support interfaces that
are not part of the integrated file system support. Applications that use
these interfaces may no longer be able to access objects that are moved to
another file system. For example, the QDLS and
QOPT file systems support the hierarchical file system (HFS) APIs and commands
to work with document and folder objects. You cannot use these interfaces
on objects that are in other file systems.
- What characteristics of the objects are important to you?
Not all
characteristics are supported by all file systems. For example, the QSYS.LIB
or independent ASP QSYS.LIB file systems support storing and retrieving only
a few extended attributes, whereas the "root" (/) and QOpenSys file systems
support storing and retrieving all extended attributes. Therefore QSYS.LIB
and independent ASP QSYS.LIB are not good candidates for storing objects that
have extended attributes.
Good candidates for moving are the PC files
that are in stored in QDLS. Most PC applications should be able to continue
working with PC files that are moved from QDLS to other file systems. The
"root" (/), QOpenSys, QNetWare, and QNTC file systems are good choices for
storing these PC files. Because they support many of the OS/2® file system
characteristics, these file systems can provide faster access to files.
To move objects to another file system, perform the following steps:
- Save a copy of all objects that you are planning to move.
Having a backup copy allows you to restore the objects to the original
file system if you find that applications cannot access the objects in the
file system to which you have moved them.
Note: You cannot save objects
from one file system and restore them to another.
- Create the directories in the file system that you want to move
the objects to using the Create Directory (CRTDIR) command.
You should carefully examine the attributes of the directory the
objects are currently in to determine if you want to duplicate those attributes
on the directories you create. For example, the user who creates the directory
is its owner, rather than the user who owned the old directory. You may want
to transfer ownership of the directory after you have created it, if the file
system supports setting the owner of a directory.
- Move the files to the file system that you have chosen using the Move
(MOV) command.
MOV is recommended
because it preserves the ownership of the objects, if the file system supports
setting the ownership of objects. You can, however, use the Copy
(CPY) command to preserve the ownership of the objects by using
the OWNER(*KEEP) parameter. Keep in mind that this only works for file systems
that support setting the owner of an object. Note that when using MOV or CPY:
- Attributes may not match and may be discarded.
- Extended attributes may be discarded.
- Authorities may not be equivalent and may be discarded.
This means that if you decide to return the object to its original
file system, you may not want to just move or copy it back because of the
attributes and authorities that have been discarded. The safest way to return
an object is to restore a saved version of it.