view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

* File modification time should be in range from year 1000 to year 9999.

(NOTE: if above requirements are not met, error will be thrown)

* If you uploaded files with file modifications dates past Y2038 on system which supports it, and then restored on system
which does not (like Linux 32bit), resulting file timestamp (of course) wrong and also
unpredictible (undefined behaviour). The only thing is guaranteed that if you restore journal from Amazon servers on affected (i.e. 32bit)
machine - journal will contain correct timestamp (same as on 64bit).

* Memory usage (for 'sync') formula is ~ min(NUMBER_OF_FILES_TO_SYNC, max-number-of-files) + partsize*concurrency

* With high partsize*concurrency there is a risk of getting network timeouts HTTP 408/500.


## Test/Play with it

1. create empty dir MYDIR
2. Set vault name inside `cycletest.sh`
3. Run

lib/App/MtAws/FileVersions.pm  view on Meta::CPAN

# if mtime defined for both a,b - compare mtime. otherwise compare time
# if mtime equal, compare time too

# when $a->{mtime} <=> $b->{mtime} returns 0 (equal), we magicaly switch to 'time' comparsion
# when $a->{mtime} <=> $b->{mtime} returns 1 or -1, we use that
# ( defined($a->{mtime}) && defined($b->{mtime}) && ($a->{mtime} <=> $b->{mtime}) ) ||
# ( $a->{'time'} <=> $b->{'time'} );

# alternative 2:
# possible alternative formula:
#(defined($a->{mtime}) ? $a->{mtime} : $a->{time}) <=> (defined($b->{mtime}) ? $b->{mtime} : $b->{time})

sub _cmp
{
	my ($a, $b) = @_;
	# use mtime (but if missed, use time) for both values
	(
		(defined($a->{mtime}) ? $a->{mtime} : $a->{time}) # mtime1 or time1
		<=>
		(defined($b->{mtime}) ? $b->{mtime} : $b->{time}) # mtime2 or time2