Any way to know which files were skipped during a transfer?

I'm using an excludes.txt which occasionally picks up something that should have been sent and when that happens I end up with a source that has more files, eg a job that just finished has 44,639 files - of which 44,635 transferred.

Is there a way to ascertain which four files were skipped and not sent?

2019-07-28 15:06:38 INFO : Encrypted drive 'tcrypt:': Waiting for transfers to finish Transferred: 0 / 0 Bytes, -, 0 Bytes/s, ETA - Errors: 0 Checks: 44635 / 44635, 100% Transferred: 1 / 1, 100% Elapsed time: 4m7.4s

You can run the command with -vv and check the log file as that shows what's skipped and prints out a reason why.

I thought of that initially, but it prints out 40,000 instances of ': Unchanged skipping'

I only need to know the files that are absent from the destination. Is there any way to ascertain only what's missing?

Assuming these skipped files produce a unique line in the log - one possible way would be to send the log to file (or pipe it) and then filter for that specific message. (or just go search for them manually if it's not a regular thing)

It's a very roundabout way of doing it, but it should work. If there exists a more direct way of doing it in Rclone I don't know about it, but that doesn't mean it doesn't exist, only that I'm still a noob :slight_smile:

I'd probably just attack it simple first if you think something is missing. Do a count on the source and count on the destination and see if they match.

[felix@gemini GD]$ find . -type f | wc -l
[felix@gemini GD]$ rclone size gcrypt:
Total objects: 28498
Total size: 71.737 TBytes (78875510775378 Bytes)

You had initially asked for skipped. as that what would be printed in the log. If copy/sync failed to do something, it would log an error in the log and you'd see those in the log.

Transferred:      178.827G / 178.827 GBytes, 100%, 91.318 MBytes/s, ETA 0s
Errors:                 0
Checks:               250 / 250, 100%
Transferred:          125 / 125, 100%
Elapsed time:    33m25.2s

On the errors line.