Not to be that guy... but your link explains. Like right in the first 5 sentences.

The check script runs on a regular basis and polls for the lastsync file in the root of our repository layout. This file is regularly updated on the central repository, so checking the value within allows one to see if the mirror has synced recently.

There is a file called lastsync. It is read < http://mirror.csclub.uwaterloo.ca/archlinux/lastsync>

On Wed, 2014-01-15 at 11:15 -0500, Simon Gomizelj wrote:

Not to be that guy... but your link explains. Like right in the first 5 sentences.

...

The check script runs on a regular basis and polls for the lastsync file in the root of our repository layout. This file is regularly updated on the central repository, so checking the value within allows one to see if the mirror has synced recently.

There is a file called lastsync. It is read < http://mirror.csclub.uwaterloo.ca/archlinux/lastsync>

Salutations, Yes, I see that there's a check script but what is it? I'd like to know how that link calculates percent synchronization for a particular mirror. I ask this because there have been instances when a mirror is claimed to be 100% synchronized but isn't. Regards, Mark -- Mark Lee

Op 15 jan. 2014 19:17 schreef "Mark Lee" het volgende:

[...]

...

...

There is a file called lastsync. It is read < http://mirror.csclub.uwaterloo.ca/archlinux/lastsync>

Yes, I see that there's a check script but what is it? I'd like to know how that link calculates percent synchronization for a particular mirror. I ask this because there have been instances when a mirror is claimed to be 100% synchronized but isn't.

Oh I see it now, so "completion" is only a percentage of the number of times the checkscript is successfully run on a particular mirror without disconnecting.

Is the lastsync value a hash value or temporal?

As Thomas' message explains, it's a timestamp. A very nice solution if you ask me. mvg, Guus

Hi, I don't think hashes are a good way to do that. The Repositories are quite large I'm not sure what value is the right one from this [1] statistics page. Either way, after every update the mirror would effectively block for the time the hash is computed, since everything has to be read. Anyway, the time a mirror isn't in a sane state should be quite short if ever. I don't know how updates are handled, so I can't say what happens and what doesn't. Nontheless the servers normally have enough bandwidth to sync in a few seconds (I guess)... The most important part of my answer is, that this mailing list isn't the right place for discussing this topic. There is a mirror-list mailing list out there [2] cheers, Simon [1]: https://www.archlinux.de/?page=RepositoryStatistics [2]: https://mailman.archlinux.org/mailman/listinfo/arch-mirrors 2014/1/15 Mark Lee

On Wed, 2014-01-15 at 22:54 +0100, Guus Snijders wrote:

...

Op 15 jan. 2014 19:17 schreef "Mark Lee" het volgende:

...

[...]

...

...

...

There is a file called lastsync. It is read < http://mirror.csclub.uwaterloo.ca/archlinux/lastsync>

Yes, I see that there's a check script but what is it? I'd like to know how that link calculates percent synchronization for a particular mirror. I ask this because there have been instances when a mirror is claimed to be 100% synchronized but isn't.

...

Oh I see it now, so "completion" is only a percentage of the number of times the checkscript is successfully run on a particular mirror

without

...

disconnecting.

Is the lastsync value a hash value or temporal?

As Thomas' message explains, it's a timestamp. A very nice solution if you ask me.

mvg, Guus

Salutations,

I see. My concern is regarding mirrors that aren't fully up to date (I've encountered the situation before and it wasn't a packaging error at the time) and reporting this fact to the user. Instead of using a time stamp, why not use a cryptohash of a list of the files installed as the lastsync value. Pacman -Syy could then check the hash value (it grabs from the tier 1 mirror) and check it against the current mirrors it's using.

Regards, Mark -- Mark Lee