+=head2 UMASK
+
+Certain calls are affected by the current file mode creation mask (the
+"umask"). In particular ones which create files or directories, such
+as L</guestfs_touch>, L</guestfs_mknod> or L</guestfs_mkdir>. This
+affects either the default mode that the file is created with or
+modifies the mode that you supply.
+
+The default umask is C<022>, so files are created with modes such as
+C<0644> and directories with C<0755>.
+
+There are two ways to avoid being affected by umask. Either set umask
+to 0 (call C<guestfs_umask (g, 0)> early after launching). Or call
+L</guestfs_chmod> after creating each file or directory.
+
+For more information about umask, see L<umask(2)>.
+
+=head2 ENCRYPTED DISKS
+
+Libguestfs allows you to access Linux guests which have been
+encrypted using whole disk encryption that conforms to the
+Linux Unified Key Setup (LUKS) standard. This includes
+nearly all whole disk encryption systems used by modern
+Linux guests.
+
+Use L</guestfs_vfs_type> to identify LUKS-encrypted block
+devices (it returns the string C<crypto_LUKS>).
+
+Then open these devices by calling L</guestfs_luks_open>.
+Obviously you will require the passphrase!
+
+Opening a LUKS device creates a new device mapper device
+called C</dev/mapper/mapname> (where C<mapname> is the
+string you supply to L</guestfs_luks_open>).
+Reads and writes to this mapper device are decrypted from and
+encrypted to the underlying block device respectively.
+
+LVM volume groups on the device can be made visible by calling
+L</guestfs_vgscan> followed by L</guestfs_vg_activate_all>.
+The logical volume(s) can now be mounted in the usual way.
+
+Use the reverse process to close a LUKS device. Unmount
+any logical volumes on it, deactivate the volume groups
+by caling C<guestfs_vg_activate (g, 0, ["/dev/VG"])>.
+Then close the mapper device by calling
+L</guestfs_luks_close> on the C</dev/mapper/mapname>
+device (I<not> the underlying encrypted block device).
+
+=head2 INSPECTION
+
+Libguestfs has APIs for inspecting an unknown disk image to find out
+if it contains operating systems. (These APIs used to be in a
+separate Perl-only library called L<Sys::Guestfs::Lib(3)> but since
+version 1.5.3 the most frequently used part of this library has been
+rewritten in C and moved into the core code).
+
+Add all disks belonging to the unknown virtual machine and call
+L</guestfs_launch> in the usual way.
+
+Then call L</guestfs_inspect_os>. This function uses other libguestfs
+calls and certain heuristics, and returns a list of operating systems
+that were found. An empty list means none were found. A single
+element is the root filesystem of the operating system. For dual- or
+multi-boot guests, multiple roots can be returned, each one
+corresponding to a separate operating system. (Multi-boot virtual
+machines are extremely rare in the world of virtualization, but since
+this scenario can happen, we have built libguestfs to deal with it.)
+
+For each root, you can then call various C<guestfs_inspect_get_*>
+functions to get additional details about that operating system. For
+example, call L</guestfs_inspect_get_type> to return the string
+C<windows> or C<linux> for Windows and Linux-based operating systems
+respectively.
+
+Un*x-like and Linux-based operating systems usually consist of several
+filesystems which are mounted at boot time (for example, a separate
+boot partition mounted on C</boot>). The inspection rules are able to
+detect how filesystems correspond to mount points. Call
+C<guestfs_inspect_get_mountpoints> to get this mapping. It might
+return a hash table like this example:
+
+ /boot => /dev/sda1
+ / => /dev/vg_guest/lv_root
+ /usr => /dev/vg_guest/lv_usr
+
+The caller can then make calls to L</guestfs_mount_options> to
+mount the filesystems as suggested.
+
+Be careful to mount filesystems in the right order (eg. C</> before
+C</usr>). Sorting the keys of the hash by length, shortest first,
+should work.
+
+Inspection currently only works for some common operating systems.
+Contributors are welcome to send patches for other operating systems
+that we currently cannot detect.
+
+Encrypted disks must be opened before inspection. See
+L</ENCRYPTED DISKS> for more details. The L</guestfs_inspect_os>
+function just ignores any encrypted devices.
+
+A note on the implementation: The call L</guestfs_inspect_os> performs
+inspection and caches the results in the guest handle. Subsequent
+calls to C<guestfs_inspect_get_*> return this cached information, but
+I<do not> re-read the disks. If you change the content of the guest
+disks, you can redo inspection by calling L</guestfs_inspect_os>
+again.
+