删除桶名称后似乎仍在使用
Bucket name seems to still be in use after deleting it
使用 Java S3 SDK，我可以创建存储桶并将对象放入其中，列出内容并删除存储桶。我唯一不能做的就是删除后再次创建相同的存储桶。
在下面显示的堆栈跟踪中，我之前创建了一个名为 gormanm-0709-r-o-o-t 的存储桶，使用了它，然后通过 s3.deleteBucket("gormanm-0709-r-o-o-t") 删除了它。然后我尝试通过 s3.createBucket("gormanm-0709-r-o-o-t", "us-standard") 重新创建它，但出现如下所示的错误。
com.amazonaws.services.s3.model.AmazonS3Exception: Container gormanm-0709-r-o-o-t exists (Service: Amazon S3; Status Code: 409; Error Code: BucketAlreadyExists; Request ID: 1be8b569-3db4-4eff-bf1e-c4b8dac20272), S3 Extended Request ID: null
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1588)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1258)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1030)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:742)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:716)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:699)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access0(AmazonHttpClient.java:667)
at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:649)
at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:513)
at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4187)
at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4134)
at com.amazonaws.services.s3.AmazonS3Client.createBucket(AmazonS3Client.java:1021)
at com.amazonaws.services.s3.AmazonS3Client.createBucket(AmazonS3Client.java:973)
at com.ibm.saas.file.cos.CosFile.createBucket(CosFile.java:794)
at com.ibm.saas.file.cos.CosFile.ensureBucketExists(CosFile.java:781)
at com.ibm.saas.file.cos.CosFile.mkdirs(CosFile.java:665)
at com.ibm.saas.file.cos.CosFileServiceTest.testDir(CosFileServiceTest.java:148)
at com.ibm.saas.file.cos.CosFileServiceTest.testRootOperations(CosFileServiceTest.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access[=10=]0(ParentRunner.java:53)
at org.junit.runners.ParentRunner.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
我确定我删除了它（因为代码没有抛出任何异常并且我没有看到该存储桶出现在 Bluemix/Softlayer 控制台中）并且我确定没有其他人 "jumped on" 我的存储桶名称，因为我一遍又一遍地进行了此测试。
我的猜测是，在存储桶名称再次可供使用之前还有一段时间，但我只是猜测，即使那是真的，也应该有一些文档在某处解释规则。
说到文档，Getting Help page says to go here (https://developer.ibm.com/answers/smartspace/public-cloud-object-storage/) 的问题，但该页面不存在。
来自 S3 开发人员指南：
Bucket ownership is not transferable; however, if a bucket is empty, you can delete it. After a bucket is deleted, the name becomes available to reuse, but the name might not be available for you to reuse for various reasons. For example, some other account could create a bucket with that name. Note, too, that it might take some time before the name can be reused. So if you want to use the same bucket name, don't delete the bucket. [emphasis added]
http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
这里有关于预期延迟的文档，还有一个额外的好处：你真的不应该删除和重新创建存储桶。由于桶命名空间是全局的，因此在任何给定时间只能存在一个给定名称的桶，并且它当然只能在一个区域中。桶仅在您不再需要它们时才被删除——否则，清空桶中的对象，但保留桶。有人可能会抢购这个名字，如果它不是特别晦涩的话。另外：
The high-availability engineering of Amazon S3 is focused on get, put, list, and delete operations. Because bucket operations work against a centralized, global resource space, it is not appropriate to create or delete buckets on the high-availability code path of your application. It is better to create or delete buckets in a separate initialization or setup routine that you run less often.
http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
虽然细节不public，但所有 S3 区域在某种意义上都知道所有存储桶。如果您将 S3 请求发送到错误的区域，该错误的区域确实知道正确的区域，并且将 return 一个包含（显然未记录）.
的错误
因此，当创建存储桶时——无论区域如何——在创建存储桶时必然会与 S3 全局数据库进行一些内部通信。此处的中断可能会阻止在任何区域创建存储桶，即使该区域在其他方面正常运行也是如此。
请注意，在撰写本文时，文档的另一部分 S3 入门指南提供了基本相同的信息；但是，至少在 2015 年底之前，那里提供的信息有所不同。
When you delete a bucket, there may be a delay of up to one hour before the bucket name is available for reuse in a new region or by a new bucket owner. If you re-create the bucket in the same region or with the same bucket owner, there is no delay.
直觉上，我怀疑 S3 的持续增长可能使这些信息在它被删除之前就已经过时了，而且在 2015 年的这个快照之前。
在 IBM COS 中，存储桶删除后有 10 分钟的时间保留名称。此延迟可防止可能的缓存问题，即命令可能会写入已删除的存储桶。发生这种情况的可能性很小，我们可能会将 window 缩小一点，但一般来说，删除和重新创建存储桶并不是一个好的做法。您是否有特殊原因需要能够在您的工作流程中执行此操作？
是的，正如@jarmod 在顶级评论中提到的，这种行为是由于控制对象切片和重组的大量分布式逻辑设备造成的。存储桶删除仍然大部分 立即一致，因为在收到 204 响应后将无法进行写入和列表，但可以更好地记录此行为。
虽然 Michael 的回答指的是 AWS S3，但该信息对于我们的实施也或多或少是准确的。
使用 Java S3 SDK，我可以创建存储桶并将对象放入其中，列出内容并删除存储桶。我唯一不能做的就是删除后再次创建相同的存储桶。
在下面显示的堆栈跟踪中，我之前创建了一个名为 gormanm-0709-r-o-o-t 的存储桶，使用了它，然后通过 s3.deleteBucket("gormanm-0709-r-o-o-t") 删除了它。然后我尝试通过 s3.createBucket("gormanm-0709-r-o-o-t", "us-standard") 重新创建它，但出现如下所示的错误。
com.amazonaws.services.s3.model.AmazonS3Exception: Container gormanm-0709-r-o-o-t exists (Service: Amazon S3; Status Code: 409; Error Code: BucketAlreadyExists; Request ID: 1be8b569-3db4-4eff-bf1e-c4b8dac20272), S3 Extended Request ID: null
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1588)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1258)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1030)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:742)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:716)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:699)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access0(AmazonHttpClient.java:667)
at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:649)
at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:513)
at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4187)
at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4134)
at com.amazonaws.services.s3.AmazonS3Client.createBucket(AmazonS3Client.java:1021)
at com.amazonaws.services.s3.AmazonS3Client.createBucket(AmazonS3Client.java:973)
at com.ibm.saas.file.cos.CosFile.createBucket(CosFile.java:794)
at com.ibm.saas.file.cos.CosFile.ensureBucketExists(CosFile.java:781)
at com.ibm.saas.file.cos.CosFile.mkdirs(CosFile.java:665)
at com.ibm.saas.file.cos.CosFileServiceTest.testDir(CosFileServiceTest.java:148)
at com.ibm.saas.file.cos.CosFileServiceTest.testRootOperations(CosFileServiceTest.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access[=10=]0(ParentRunner.java:53)
at org.junit.runners.ParentRunner.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
我确定我删除了它（因为代码没有抛出任何异常并且我没有看到该存储桶出现在 Bluemix/Softlayer 控制台中）并且我确定没有其他人 "jumped on" 我的存储桶名称，因为我一遍又一遍地进行了此测试。
我的猜测是，在存储桶名称再次可供使用之前还有一段时间，但我只是猜测，即使那是真的，也应该有一些文档在某处解释规则。
说到文档，Getting Help page says to go here (https://developer.ibm.com/answers/smartspace/public-cloud-object-storage/) 的问题，但该页面不存在。
来自 S3 开发人员指南：
Bucket ownership is not transferable; however, if a bucket is empty, you can delete it. After a bucket is deleted, the name becomes available to reuse, but the name might not be available for you to reuse for various reasons. For example, some other account could create a bucket with that name. Note, too, that it might take some time before the name can be reused. So if you want to use the same bucket name, don't delete the bucket. [emphasis added]
http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
这里有关于预期延迟的文档，还有一个额外的好处：你真的不应该删除和重新创建存储桶。由于桶命名空间是全局的，因此在任何给定时间只能存在一个给定名称的桶，并且它当然只能在一个区域中。桶仅在您不再需要它们时才被删除——否则，清空桶中的对象，但保留桶。有人可能会抢购这个名字，如果它不是特别晦涩的话。另外：
The high-availability engineering of Amazon S3 is focused on get, put, list, and delete operations. Because bucket operations work against a centralized, global resource space, it is not appropriate to create or delete buckets on the high-availability code path of your application. It is better to create or delete buckets in a separate initialization or setup routine that you run less often.
http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
虽然细节不public，但所有 S3 区域在某种意义上都知道所有存储桶。如果您将 S3 请求发送到错误的区域，该错误的区域确实知道正确的区域，并且将 return 一个包含（显然未记录）
因此，当创建存储桶时——无论区域如何——在创建存储桶时必然会与 S3 全局数据库进行一些内部通信。此处的中断可能会阻止在任何区域创建存储桶，即使该区域在其他方面正常运行也是如此。
请注意，在撰写本文时，文档的另一部分 S3 入门指南提供了基本相同的信息；但是，至少在 2015 年底之前，那里提供的信息有所不同。
When you delete a bucket, there may be a delay of up to one hour before the bucket name is available for reuse in a new region or by a new bucket owner. If you re-create the bucket in the same region or with the same bucket owner, there is no delay.
直觉上，我怀疑 S3 的持续增长可能使这些信息在它被删除之前就已经过时了，而且在 2015 年的这个快照之前。
在 IBM COS 中，存储桶删除后有 10 分钟的时间保留名称。此延迟可防止可能的缓存问题，即命令可能会写入已删除的存储桶。发生这种情况的可能性很小，我们可能会将 window 缩小一点，但一般来说，删除和重新创建存储桶并不是一个好的做法。您是否有特殊原因需要能够在您的工作流程中执行此操作？
是的，正如@jarmod 在顶级评论中提到的，这种行为是由于控制对象切片和重组的大量分布式逻辑设备造成的。存储桶删除仍然大部分 立即一致，因为在收到 204 响应后将无法进行写入和列表，但可以更好地记录此行为。
虽然 Michael 的回答指的是 AWS S3，但该信息对于我们的实施也或多或少是准确的。