Index: tools/telemetry/third_party/gsutil/third_party/boto/boto/file/README |
diff --git a/tools/telemetry/third_party/gsutil/third_party/boto/boto/file/README b/tools/telemetry/third_party/gsutil/third_party/boto/boto/file/README |
deleted file mode 100644 |
index af824554e162c99fb97846c01d64cfd31427f794..0000000000000000000000000000000000000000 |
--- a/tools/telemetry/third_party/gsutil/third_party/boto/boto/file/README |
+++ /dev/null |
@@ -1,49 +0,0 @@ |
-Handling of file:// URIs: |
- |
-This directory contains code to map basic boto connection, bucket, and key |
-operations onto files in the local filesystem, in support of file:// |
-URI operations. |
- |
-Bucket storage operations cannot be mapped completely onto a file system |
-because of the different naming semantics in these types of systems: the |
-former have a flat name space of objects within each named bucket; the |
-latter have a hierarchical name space of files, and nothing corresponding to |
-the notion of a bucket. The mapping we selected was guided by the desire |
-to achieve meaningful semantics for a useful subset of operations that can |
-be implemented polymorphically across both types of systems. We considered |
-several possibilities for mapping path names to bucket + object name: |
- |
-1) bucket = the file system root or local directory (for absolute vs |
-relative file:// URIs, respectively) and object = remainder of path. |
-We discarded this choice because the get_all_keys() method doesn't make |
-sense under this approach: Enumerating all files under the root or current |
-directory could include more than the caller intended. For example, |
-StorageUri("file:///usr/bin/X11/vim").get_all_keys() would enumerate all |
-files in the file system. |
- |
-2) bucket is treated mostly as an anonymous placeholder, with the object |
-name holding the URI path (minus the "file://" part). Two sub-options, |
-for object enumeration (the get_all_keys() call): |
- a) disallow get_all_keys(). This isn't great, as then the caller must |
- know the URI type before deciding whether to make this call. |
- b) return the single key for which this "bucket" was defined. |
- Note that this option means the app cannot use this API for listing |
- contents of the file system. While that makes the API less generally |
- useful, it avoids the potentially dangerous/unintended consequences |
- noted in option (1) above. |
- |
-We selected 2b, resulting in a class hierarchy where StorageUri is an abstract |
-class, with FileStorageUri and BucketStorageUri subclasses. |
- |
-Some additional notes: |
- |
-BucketStorageUri and FileStorageUri each implement these methods: |
- - clone_replace_name() creates a same-type URI with a |
- different object name - which is useful for various enumeration cases |
- (e.g., implementing wildcarding in a command line utility). |
- - names_container() determines if the given URI names a container for |
- multiple objects/files - i.e., a bucket or directory. |
- - names_singleton() determines if the given URI names an individual object |
- or file. |
- - is_file_uri() and is_cloud_uri() determine if the given URI is a |
- FileStorageUri or BucketStorageUri, respectively |