X-Git-Url: http://git.annexia.org/?a=blobdiff_plain;f=src%2Fguestfs.pod;h=c22ad51715e664ae9bb26651dadf1a07e01f4b3e;hb=2b0ca7e7b8d369a42a51b1feec72ae8f17257c78;hp=b4607db893d7afb9e5bae5ce06f7080b2e9d8457;hpb=50e59c237081b2bda36e5a04ecdf446a7fc3ec4c;p=libguestfs.git

diff --git a/src/guestfs.pod b/src/guestfs.pod
index b4607db..c22ad51 100644
--- a/src/guestfs.pod
+++ b/src/guestfs.pod
@@ -641,16 +641,15 @@ you might find a Windows configuration file referring to a path like
 C<c:\windows\system32>.  When the filesystem is mounted in libguestfs,
 that directory might be referred to as C</WINDOWS/System32>.
 
-Drive letter mappings are outside the scope of libguestfs.  You have
-to use libguestfs to read the appropriate Windows Registry and
-configuration files, to determine yourself how drives are mapped (see
-also L<hivex(3)> and L<virt-inspector(1)>).
+Drive letter mappings can be found using inspection
+(see L</INSPECTION> and L</guestfs_inspect_get_drive_mappings>)
 
-Replacing backslash characters with forward slash characters is also
-outside the scope of libguestfs, but something that you can easily do.
+Dealing with separator characters (backslash vs forward slash) is
+outside the scope of libguestfs, but usually a simple character
+replacement will work.
 
-Where we can help is in resolving the case insensitivity of paths.
-For this, call L</guestfs_case_sensitive_path>.
+To resolve the case insensitivity of paths, call
+L</guestfs_case_sensitive_path>.
 
 =head3 ACCESSING THE WINDOWS REGISTRY
 
@@ -1779,12 +1778,27 @@ indicator which shows the ratio of C<position>:C<total>.
 =item *
 
 If any progress notification is sent during a call, then a final
-progress notification is always sent when C<position> = C<total>.
+progress notification is always sent when C<position> = C<total>
+(I<unless> the call fails with an error).
 
 This is to simplify caller code, so callers can easily set the
 progress indicator to "100%" at the end of the operation, without
 requiring special code to detect this case.
 
+=item *
+
+For some calls we are unable to estimate the progress of the call, but
+we can still generate progress messages to indicate activity.  This is
+known as "pulse mode", and is directly supported by certain progress
+bar implementations (eg. GtkProgressBar).
+
+For these calls, zero or more progress messages are generated with
+C<position = 0> and C<total = 1>, followed by a final message with
+C<position = total = 1>.
+
+As noted above, if the call fails with an error then the final message
+may not be generated.
+
 =back
 
 The callback also receives the procedure number (C<proc_nr>) and