[libtorrent] Question about ignore_resume_timestamp

[Calum Lind]

I see that `ignore_resume_timestamp` setting defaults to false and only
suggested to be turned on if connected to high-speed network.

However after making some changes with catching rejected fastresume there
are often torrents that fail with mismatching timestamp which might be a
'bad' shutdown of deluge however logs often show clean save of resume data
and shutdown...

I did notice in git master branch that you have removed this feature so
does this mean you would now suggest enabling `ignore_resume_timestamp`
setting in older versions of libtorrent?

[M***@massaroddel.de]

Post by Calum Lind
I see that `ignore_resume_timestamp` setting defaults to false and only
suggested to be turned on if connected to high-speed network.
However after making some changes with catching rejected fastresume there
are often torrents that fail with mismatching timestamp which might be a
'bad' shutdown of deluge however logs often show clean save of resume data
and shutdown...

One known problem was that if a torrent was never active during a session then libtorrent
never touched the files and knows nothing about file timestamps. In that case fast resume
data did not contain timestamps. So, next time you loaded these resume data - they would
get rejected.
I cannot remember if it is fixed or not. The workaround would be to not generate new fast
resume data for torrents which were never active.

MassaRoddel

[Arvid Norberg]

Post by Calum Lind
I see that `ignore_resume_timestamp` setting defaults to false and only
suggested to be turned on if connected to high-speed network.
However after making some changes with catching rejected fastresume there
are often torrents that fail with mismatching timestamp which might be a
'bad' shutdown of deluge however logs often show clean save of resume data
and shutdown...

One observation I've made is that timestamps don't round-trip to filesystem
accurately and reliably. Especially on filesystems like FAT, where the
granularity is 2 seconds iirc. This, along with other external factors,
like daylight savings altering file timestamps, made the file timestamp
difficult to rely on.

Post by Calum Lind
I did notice in git master branch that you have removed this feature so
does this mean you would now suggest enabling `ignore_resume_timestamp`
setting in older versions of libtorrent?

The short answer is yes. The main reason to check the timestamps in the
first place, back in the day, was because of compact piece allocation. If
downloading more data to files may *move* pieces, it's critical to make
sure that nothing has been downloaded since the resume data was saved (say,
the client crashing for instance). Compact allocation has since been
deprecated and removed, so there's no strong reason to enforce the
timestamps anymore. The worst thing that happens is that you may loose some
download progress if you download more after the last resume data.

So, presumably you don't use compact allocation anymore, and you don't have
that option. In which case it should be safe to also enable the
ignore_resume_timestamp
setting.