[ https://issues.apache.org/jira/browse/HDFS-15982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17359902#comment-17359902 ]
Viraj Jasani edited comment on HDFS-15982 at 6/9/21, 3:46 PM: -------------------------------------------------------------- {quote}delete(path) MUST be a no-op if the path isn't there. The way to view the semantics of the call is that delete(path) == true implies the path is no longer present. {quote} [~ste...@apache.org] It seems that we don't follow this everywhere. DFS client (NameNode -> FSNameSystem#delete -> FSDirDeleteOp#delete -> deleteInternal -> delete -> deleteAllowed) doesn't follow this and I just quickly tested Http FS with WebHdfs and LocalFS, and this semantic is not followed. For non existing file, FS#delete returns false. Although I agree that delete(path) should return true for non-existing path, if we change this behaviour (as part of separate Jira), it will be another incompatible change. Edit: Even Abfs returns false while deleting non-existent path it seems {code:java} try { abfsStore.delete(qualifiedPath, recursive); return true; } catch (AzureBlobFileSystemException ex) { checkException(f, ex, AzureServiceErrorCode.PATH_NOT_FOUND); return false; } {code} was (Author: vjasani): {quote}delete(path) MUST be a no-op if the path isn't there. The way to view the semantics of the call is that delete(path) == true implies the path is no longer present. {quote} [~ste...@apache.org] It seems that we don't follow this everywhere. DFS client (NameNode -> FSNameSystem#delete -> FSDirDeleteOp#delete -> deleteInternal -> delete -> deleteAllowed) doesn't follow this and I just quickly tested Http FS with WebHdfs and LocalFS, and this semantic is not followed. For non existing file, FS#delete returns false. Although I agree that delete(path) should return true for non-existing path, if we change this behaviour (as part of separate Jira), it will be another incompatible change. Edit: Even Abfs returns false while deleting non-existent path it seems {code:java} try { abfsStore.delete(qualifiedPath, recursive); return true; } catch (AzureBlobFileSystemException ex) { checkException(f, ex, AzureServiceErrorCode.PATH_NOT_FOUND); return false; } {code} > Deleted data using HTTP API should be saved to the trash > -------------------------------------------------------- > > Key: HDFS-15982 > URL: https://issues.apache.org/jira/browse/HDFS-15982 > Project: Hadoop HDFS > Issue Type: New Feature > Components: hdfs, hdfs-client, httpfs, webhdfs > Reporter: Bhavik Patel > Assignee: Viraj Jasani > Priority: Major > Labels: pull-request-available > Attachments: Screenshot 2021-04-23 at 4.19.42 PM.png, Screenshot > 2021-04-23 at 4.36.57 PM.png > > Time Spent: 13h 20m > Remaining Estimate: 0h > > If we delete the data from the Web UI then it should be first moved to > configured/default Trash directory and after the trash interval time, it > should be removed. currently, data directly removed from the system[This > behavior should be the same as CLI cmd] > This can be helpful when the user accidentally deletes data from the Web UI. > Similarly we should provide "Skip Trash" option in HTTP API as well which > should be accessible through Web UI. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org