Manual Pages


Table of Contents

NAME

na_charmap - command for managing per-volume character maps

SYNOPSIS

charmap [ volname [ mapspec ] ]

DESCRIPTION

The charmap command can be used to manage a character map which is used to allow CIFS clients to access files with NFS names that would otherwise not be valid for CIFS. Without a mapping, in such a case the CIFS client will see and must use the 8.3 format name that ONTAP generates for these names.

USAGE

charmap volname mapspec

This form of the command associates the mapspec with the named volume. The format of the mapspec is as follows:

hh:hhhh[,hh:hhhh]...

Each "hh" represents a hexadecimal value. It does not have to be zero-padded, and upper- or lowercase hex "A"-"F" are accepted. The first value of each colon-separated pair is the hex value of the NFS byte to be translated, and the second value is the Unicode value to be substituted for CIFS use. See the "Examples" section below to see how this is done.

charmap volname ""

This command will remove any existing mapping from the named volume.

charmap [volname]

Without a mapspec, the existing character map for the named volume is displayed. If no volume is named, the character map, if any, for each volume is displayed.

EXAMPLES

charmap desvol 3e:ff76,3c:ff77,2a:ff78,3a:ff79

This command will map a set of characters (>, <, *, and :) into Japanese Unicode characters that are not normally used as normal characters in filenames. This mapping will apply to the volume named "desvol".

NOTES

The NFS characters that can be remapped are restricted to those that are invalid for Windows: " (22 = double quote), * (2A = asterisk), : (3A = colon), < (3C = less than), > (3E = greater than), ? (3F = question mark), \ (5C = backslash), and (7C = pipe). Values from 01 to 1F can also be mapped.

It is important to note that the Unicode characters must not appear normally in existing filenames, because otherwise unwanted mappings would occur, resulting in loss of the ability to access mapped files. For example, if ":" were mapped to "-", but "-" appeared in files normally, a Windows client using the mapped share to access a file named "a-b" would have its request mapped to the NFS name "a:b", which is not the desired file.

Note also that only CIFS client accesses will have this mapping. The on-disk names are the same as they would be if an NFS client were creating/operating using the mapped file names. If the mapping is later changed, the UNIX names and DOS 8.3 names will not be affected.

If a volume is read-only, it is still possible to assign a charmap to it. However the value will not be persistent.

BUGS

The characters of the NFS name are considered one byte at a time. that means that multi-byte character sets may have false substitutions. In general it is advisable to avoid multi-byte character sets in the names of files to be mapped.

LIMITATIONS

Case sensitivity

Because the mapped Windows names turn into NFS names, the lookup of the names follows NFS semantics. That includes the fact that NFS lookups are case-sensitive. That means the applications accessing mapped shares must not rely on Windows case-insensitive behavior. However the 8.3 name is available, and that is case-insensitive.

Partial or invalid mappings

After mapping a name to return to clients doing directory enumeration ("dir"), the resulting Unicode name is checked for Windows validity. If that name still has invalid characters in it, or if it is otherwise invalid for Windows (e.g. it ends in "." or blank) the 8.3 name is returned instead of the invalid name.


Table of Contents