[ 
https://issues.apache.org/jira/browse/HADOOP-19217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18052603#comment-18052603
 ] 

ASF GitHub Bot commented on HADOOP-19217:
-----------------------------------------

ivandika3 commented on code in PR #8063:
URL: https://github.com/apache/hadoop/pull/8063#discussion_r2700676534


##########
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java:
##########
@@ -3429,6 +3429,29 @@ public Collection<? extends BlockStoragePolicySpi> 
getAllStoragePolicies()
         + " doesn't support getAllStoragePolicies");
   }
 
+  /**
+   * Get the trash policy implementation used by this FileSystem. This trash 
policy
+   * is used by classes of {@link Trash} to implement the trash behavior.
+   * <p>
+   * FileSystem implementation can consider overriding this method to handle
+   * situation where a single FileSystem client shares a configuration, but
+   * each FileSystem scheme requires a distinct TrashPolicy implementation.
+   *
+   * @param conf configuration which can be used to choose the TrashPolicy
+   *             implementation.
+   * @return TrashPolicy implementation by this filesystem.
+   *         The default implementation returns the configured TrashPolicy
+   *         based on the value of the configuration parameter 
fs.trash.classname
+   *         of the passed configuration.
+   */
+  @InterfaceAudience.Public
+  @InterfaceStability.Unstable
+  public TrashPolicy getTrashPolicy(Configuration conf) {

Review Comment:
   Good point, updated.
   
   However, the reason I don't put the `Path` is because the `FileSystem` 
resolution logic is already done in `Trash#moveToAppropriateTrash`. In that 
case, we might not need to use a `Path`. This is the reason why I mentioned in 
the filesystem.md that 
   
   > FileSystem implementations with multiple child file systems (e.g. 
`ViewFileSystem`) should NOT implement this method since the Hadoop trash 
mechanism should resolve to the underlying filesystem before invoking 
`getTrashPolicy`. 
   
   Please let me know what you think.





> Introduce getTrashPolicy to FileSystem API
> ------------------------------------------
>
>                 Key: HADOOP-19217
>                 URL: https://issues.apache.org/jira/browse/HADOOP-19217
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: fs
>            Reporter: Ivan Andika
>            Priority: Major
>              Labels: pull-request-available
>
> Hadoop FileSystem supports multiple FileSystem implementations awareness 
> (e.g. client is aware of both hdfs:// and ofs:// protocols).
> However, it seems that currently Hadoop TrashPolicy remains the same 
> regardless of the URI scheme. The TrashPolicy is governed by 
> "fs.trash.classname" configuration and stays the same regardless of the 
> FileSystem implementation. For example, HDFS defaults to TrashPolicyDefault 
> and Ozone defaults to TrashPolicyOzone, but only one will be picked since the 
> the configuration will be overwritten by the other.
> Therefore, I propose to tie the TrashPolicy implementation to each FileSystem 
> implementation by introducing a new FileSystem#getTrashPolicy interface. 
> TrashPolicy#getInstance can call FileSystem#getTrashPolicy to get the 
> appropriate TrashPolicy.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to