1 files changed, 68 insertions, 0 deletions
diff --git a/plugins/FTPFileYM/curl/lib/README.curl_off_t b/plugins/FTPFileYM/curl/lib/README.curl_off_t
new file mode 100644
index 0000000000..923b2774cd
--- /dev/null
+++ b/plugins/FTPFileYM/curl/lib/README.curl_off_t
@@ -0,0 +1,68 @@
+
+   curl_off_t explained
+   ====================
+
+curl_off_t is a data type provided by the external libcurl include headers. It
+is the type meant to be used for the curl_easy_setopt() options that end with
+LARGE. The type is 64bit large on most modern platforms.
+
+Transition from < 7.19.0 to >= 7.19.0
+-------------------------------------
+
+Applications that used libcurl before 7.19.0 that are rebuilt with a libcurl
+that is 7.19.0 or later may or may not have to worry about anything of
+this. We have made a significant effort to make the transition really seamless
+and transparent.
+
+You have have to take notice if you are in one of the following situations:
+
+o Your app is using or will after the transition use a libcurl that is built
+  with LFS (large file support) disabled even though your system otherwise
+  supports it.
+
+o Your app is using or will after the transition use a libcurl that doesn't
+  support LFS at all, but your system and compiler support 64bit data types.
+
+In both these cases, the curl_off_t type will now (after the transition) be
+64bit where it previously was 32bit. This will cause a binary incompatibility
+that you MAY need to deal with.
+
+Benefits
+--------
+
+This new way has several benefits:
+
+o Platforms without LFS support can still use libcurl to do >32 bit file
+  transfers and range operations etc as long as they have >32 bit data-types
+  supported.
+
+o Applications will no longer easily build with the curl_off_t size
+  mismatched, which has been a very frequent (and annoying) problem with
+  libcurl <= 7.18.2
+
+Historically
+------------
+
+Previously, before 7.19.0, the curl_off_t type would be rather strongly
+connected to the size of the system off_t type, where currently curl_off_t is
+independent of that.
+
+The strong connection to off_t made it troublesome for application authors
+since when they did mistakes, they could get curl_off_t type of different
+sizes in the app vs libcurl, and that caused strange effects that were hard to
+track and detect by users of libcurl.
+
+SONAME
+------
+
+We opted to not bump the soname for the library unconditionally, simply
+because soname bumping is causing a lot of grief and moaning all over the
+community so we try to keep that at minimum. Also, our selected design path
+should be 100% backwards compatible for the vast majority of all libcurl
+users.
+
+Enforce SONAME bump
+-------------------
+
+If configure doesn't detect your case where a bump is necessary, re-run it
+with the --enable-soname-bump command line option!