How to ignore empty directories when uploading from Windows?

Suspected Bug
21

Without having followed the topic in detail, I noticed one comment in an issue that has been created:

Conversely, if I only need to copy specific files from the remote to the local (using --include ), but other irrelevant folders under that path on the remote will also be created on my local machine with the original structure. This did not exist in previous versions and is a bit annoying.

That sounds like something that could be closer to the regression side than the improvement side of the discussion, or..?

1 Like
22

I think technically the --include filtering behavior also worked like that in v1.65.2:

rclone tree test --include E.txt  
/
├── E.txt
├── a
│   └── d
├── b
└── c

4 directories, 1 files

vs. with a slash:

rclone tree test --include /E.txt
/
└── E.txt

0 directories, 1 files

Both examples above are using:

rclone v1.65.2
- os/version: darwin 14.3.1 (64 bit)
- os/kernel: 23.3.0 (arm64)
- os/type: darwin
- os/arch: arm64 (ARMv8 compatible)
- go/version: go1.21.6
- go/linking: dynamic
- go/tags: cmount

The difference is that those empty directories were previously ignored by sync, even though they were "included". (Which to me begs the question: if they're "included", why should they be ignored?)

I agree that this filtering behavior is counterintuitive, and I'd be supportive of changing it... but that would be another "breaking change" :grimacing:

I've also been thinking for awhile that a new --dirs-from filtering option is needed, to specify which dirs should have their metadata synced. (Among other reasons, it would solve a difficult problem in bisync.)

If we're just getting into our personal wishlists of defaults we wish were different, my top picks are probably:

  1. empty dirs synced by default (with flag to disable)
  2. --checksum should not imply ignoring modtime
  3. --metadata enabled by default
  4. --fix-case enabled by default

But that's just my personal preference -- I'm sure some users will disagree :sweat_smile:

23

Please do as it's best for you to implement.

As long as I can specify a flag or rely on defaults to restore the 1.65.2 behavior and avoid the 32x performance hit, I'm fine with either options.

1 Like
24

This is being tracked in this issue

I plan to fix this for the point release

1 Like
25

Please try this fix

v1.67.0-beta.7855.13c72a94e.fix-7689-empty-dirs on branch fix-7689-empty-dirs (uploaded in 15-30 mins)

It should restore v1.65.2 behaviour

26

Thanks for testing :slight_smile:

I've merged this to master now which means it will be in the latest beta in 15-30 minutes and released in v1.66.1

1 Like