How do I delete all the contents of a folder?

If I use rclone purge, all contents of the folder and the path are deleted.

If I use rclone delete, all objects are deleted, not the folders.

If I use rclone rmdir/rclone rmdirs, the folders need to be empty, which it isn't.

Is there a way to delete all the contents of a folder without using rclone delete and rclone rmdirs, one after the other?

No, I don't think you can do that in a single command. It would be nice for 'rclone purge' to obey the flag '--leave-root' so that it would not delete the current directory. Perhaps that could be a enhancement request.

1 Like

Purge is specifically delete this directory and all contents and is implemented by some cloud providers so you can get rid of a directory very quickly with a single API call.

That said if purge had a --leave-root flag then it could run the fallback path (which does iterate and delete each file and directory) so it would be relatively easy to implement, but might be inefficient.

You can see which backends support purge here:

@agneev which backend are you using?

I’m using drive.

The other option could be for the delete command to also rmdirs on the touched directories but I also see this as being possibly inefficient because it would need to check they were empty for each file deletion or run it at the end only on the 'touched' directories but it doesn't keep track.

EDIT: Seems the option on purge would be more efficient than the option on the delete. I suppose the inefficiency can't be less efficient than having to run a delete and then a rmdirs though.

1 Like

Exactly. This applies to move as well, where directories are left behind.

Move has this though. If you move certain files and don't move all of them they are not empty and thus can't be deleted.


If you use filtering, then there may be files that are left behind in the folder after moving, so that flag won’t work.

Correct so how would you expect rclone to understand that it should delete those folders if you've filtered?

Is this what you're meaning?

root@cloudc:/tmp# rclone lsl robgd:testcase
      241 2020-03-10 03:00:25.474000000 exc2
      241 2020-03-10 03:00:25.474000000 exc
root@cloudc:/tmp# rclone lsl robgd:testcase2
root@cloudc:/tmp# rclone move robgd:testcase robgd:testcase2/
root@cloudc:/tmp# rclone lsl robgd:testcase2
      241 2020-03-10 03:00:25.474000000 exc2
      241 2020-03-10 03:00:25.474000000 exc
root@cloudc:/tmp# rclone lsl robgd:testcase
root@cloudc:/tmp# rclone moveto robgd:testcase2/ ^C
root@cloudc:/tmp# rclone move robgd:testcase2 robgd:testcase --delete-empty-src-dirs
root@cloudc:/tmp# rclone lsl robgd:testcase
      241 2020-03-10 03:00:25.474000000 exc2
      241 2020-03-10 03:00:25.474000000 exc
**root@cloudc:/tmp# rclone lsl robgd:testcase2**

The root directory? It leaves that because its the root.

Would moveto work for you?

root@cloudc:/tmp# rclone moveto robgd:testcase2 robgd:testroot/testcase2/
root@cloudc:/tmp# rclone lsl robgd:testcase2                                                                                             
2020/03/10 12:01:00 Failed to lsl: directory not found

If I’ve filtered, meaning there are still files that are remaining, another command is necessary to remove them, ideally rclone delete which should expand to deleting folders too, not just objects.

As for move, let’s continue it on the other thread and leave this solely for delete and related.

1 Like

With Google drive rclone purge drive:dir runs a single command to place dir in the trash - nice and quick!

If you want the fastest solution then rclone purge drive:dir && rclone mkdir drive:dir would be that.

I guess rclone purge --leave-root could recursively run rclone purge on any directories in the root and rclone delete on any files.

So an rclone delete --rmdirs variant? That could work.

Is there a particular reason why delete leaves folders behind?
I see no reason to include flags with delete or purge.

Here’s what I think:

There are far too many options for deleting items with varying nomenclature that makes it confusing for even the most experienced people.

delete/purge/rmdir/rmdirs can all come under one command, delete, and it should behave like rm.

It comes down to efficiency. rclone doesn't keep track of whats in those directories as it deletes files. It would need additional API calls to gather as it deletes and hope that nothing was added while it was working. It leverages expensive API calls where filesystems don't.

But cloud objects and file system objects are very different hence why there are different ways of dealing with things. rm and rmdir is a linux delete tool. del, deltree acts differently and is windows. Trying to make everything look like 'rm' wouldn't work as the storage is different.

What do you think of that?

This is definitely better than what we have now, but as I keep saying, rclone delete should remove directories by default.

But please, @ncw, consider adding a confirmation to rclone purge

First step would be to create an issue.

There is already an issue in general for that.

1 Like

That is a very good issue and tells me that every operation should have --dry-run by default with -f to actually carry out the command.

Unfortunately, none of it has been implemented thus far.

There are so many commands that can blow up a system / lose data /etc and making more default things just makes using the tool harder.

You can't always protect someone from doing something.

While you might find it important (this is about perception not reality), it seems no one else picked it up nor worked on it so in that perception, it wasn't important.

Perception is reality so your perception isn't wrong just different than mine :slight_smile:


Remember rclone has about maybe 100,000 users so I can't be breaking backwards compatibility for people unless it is really really important.

I think there is an issue about that to add a --interactive flag like rm and friends have.

I have thought about adding rm cp mv commands with their exact unix semantics. This will make them less efficient than the current commands but they could be done...