Remove symlink, not target, in FileOp.Rm. #2474
Conversation
| @@ -146,10 +146,12 @@ func rm(ctx context.Context, d string, action pb.FileActionRm) error { | |||
| } | |||
|
|
|||
| func rmPath(root, src string, allowNotFound bool) error { | |||
| p, err := fs.RootPath(root, filepath.Join("/", src)) | |||
| dir, base := filepath.Split(src) | |||
There was a problem hiding this comment.
Clean() the src for safety before. And validate base not empty?
Before this change, if the path provided to FileOp.Rm was a symlink then the target of the symlink would be removed instead of the symlink itself. Now, the symlink will be removed instead. However, any symlinks present in the parent dirs of the specified path will still be resolved before calling os.Remove; this change only results in the base of the specified path not being followed. Signed-off-by: Erik Sipsma <[email protected]>
sipsma
force-pushed
the
file-rm-no-follow
branch
from
94f2a2e to
43a7426
Compare
Added a cap in the update that's set server-side, but should the client actually set that anywhere in any requests? Or is it just cap the server sets that users can query if they want? I'm not that familiar with the whole cap system and see pre-existing caps following both patterns, so not sure what's right here. |
Only if the client had an option like |
Before this change, if the path provided to FileOp.Rm was a symlink then
the target of the symlink would be removed instead of the symlink
itself. Now, the symlink will be removed instead. However, any symlinks
present in the parent dirs of the specified path will still be resolved
before calling os.Remove; this change only results in the base of the
specified path not being followed.
Signed-off-by: Erik Sipsma [email protected]