Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 4 Nov 2016 08:25:58 +0000 (UTC)
From: "Yuanbo Liu (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.13017952.1478240099000.186048.1478247958748@Atlassian.JIRA>
In-Reply-To: <JIRA.13017952.1478240099000@Atlassian.JIRA>
References: <JIRA.13017952.1478240099000@Atlassian.JIRA> <JIRA.13017952.1478240099175@arcas>
Subject: [jira] [Commented] (HDFS-11102) Deleting .Trash without -skipTrash
 should be confirmed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 04 Nov 2016 08:26:00 -0000


    [ https://issues.apache.org/jira/browse/HDFS-11102?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1563=
5649#comment-15635649 ]=20

Yuanbo Liu commented on HDFS-11102:
-----------------------------------

Prompting up info before deleting could be annoying and incompatible.
I'd prefer implementing a command like "hadoop fs -clearTrash" to clear tra=
sh safely.

> Deleting .Trash without -skipTrash should be confirmed
> ------------------------------------------------------
>
>                 Key: HDFS-11102
>                 URL: https://issues.apache.org/jira/browse/HDFS-11102
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: hdfs
>            Reporter: Lantao Jin
>
> As a Hadoop DEVOPS, I saw lots of cases that user delete their data by mi=
stake.  Most of them can be recovered from trash but the rest ones were not=
 luck.
> A system can=E2=80=99t guess user's purpose=EF=BC=8Cbut a good system sho=
uld help user to avoid their mistakes.
> There is a very common case like:
> If a user want to delete some dir from HDFS, they may use:
> {code}
> hadoop -fs -rm -r /user/someone/pathToBeDelete
> {code}
> The directory /user/someone/pathToBeDelete will move into=20
> {code}
> /user/someone/.Trash/current/user/someone/pathToBeDelete
> {code}
> If user want delete it permanently, option "-skipTrash" can be attached. =
That's the design and Hadoop knows the user's purpose well.
> Usually, user didn't use "skipTrash" for safety consideration. That's goo=
d till now.
> But the purpose is to delete some data for saving more space. Then the us=
er begin to delete it from Trash with the below command:
> {code}
> hadoop -fs -rm -r /user/someone/ .Trash
> {code}
> Why not just delete "/user/someone/.Trash/current/user/someone/pathToBeDe=
lete" is that because the user knows only pathToBeDelete in trash directory=
 now.
> The trash include pathToBeDelete will be deleted permanently.
> *But Wait! Do you see the blank space before the dot?*
> If you also type this command by "copy-paste" include some space or invis=
ible char, the whole /user/someone directory and the whole /user/someone/.T=
rash will be deleted unfortunately. *Jesus, that's means the directory /use=
r/someone is deleted permanently and unexpectedly!*
> So I think *any ".Trash" word appears in the "rm" command without "skip" =
should be launched a double checking by system to help people to avoid thei=
r mistake.*
> If you also agree this design, I will offer a patch.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org