Hi Daryn Sharp
Thank you for sharing your thoughts, I appreciate that.
It's an honor-system based sanity check for the good users. A malicious user is never going to pass the flag to request the permission subcheck. Why even hack fs -rm to remove the flag when you can just use fs -mv?
This fix is only fixed the internal code in fs, not exposed this flag to any clients. Because when trash is enabled, when user runs
hdfs dfs -rm /path/to/file
at backend, it is implemented by rename which only checks the privilege to rename. This behavior changes semantic under-cover which caused inconsistent behavior with or without -skipTrash flag, isn't it? The purpose of the fix is to prevent user to remove files which they don't have privilege to. More explanation is here .
Consider a *nix system. Let's say I foolishly have a single volume for the entire system, and I run tmpwatch to delete old stuff in /tmp. It's the same situation. If I have write privs to a directory, I can move anything in it to /tmp and it'll get blown away.
This is different, user uses mv to /tmp instead of what trash uses rm, so they know what they are doing and it still honors mv semantic. On the contrary, moving stuff to trash is using rm so if it doesn't check rm privilege seems inconsistent to me.
Please share your ideas if you agree this is a problem that we need to fix. In that case, if you have a better idea how to fix this, I would love to hear.