`fclones dedupe` results in updates to mtimes on directories about fclones

[pkolaczk]

If placed inside reflink() it would stat directories multiple times

I implemented the simplest solution for now - I placed restoring in the reflink.
I believe the performance is not a big problem in this case - stat is way faster than actual deduplicating and stat called on the same file multiple times is cached by the OS.

[th1000s]

Given the dedupe action is almost a userspace-transparent operation I agree that mtimes timestamps should not be affected.

Where is the right place to collect the timestamps beforehand? If placed inside reflink() it would stat directories multiple times, and returning the result io::Result<..> is probably annoying. Though maybe a concurrent hashmap could be passed along to skip that step if possible.

Where could it be done earlier? The iterator passed to run_script() is lazy so the stat'ing has to be woven somewhere into it - and it must reduce the result to unique directories. Not sure if this "dual flow" of files and directories is really possible.

Then the space-efficient fclones::Path has to be converted to a PathBuf to do the stat - should this be kept or should the conversion be repeated later when restoring the timestamps? Also, all other operations don't need that save-restore step at all, so skipping all this should not be expensive.