[pve-devel] [PATCH pve-storage 1/6] PVE/Storage/Plugin.pm: add ctime for backup files

Thomas Lamprecht t.lamprecht at proxmox.com
Wed Mar 4 14:45:36 CET 2020


On 3/4/20 2:11 PM, Dominik Csapak wrote:
> one comment inline
> 
> On 3/4/20 11:46 AM, Dietmar Maurer wrote:
>> Signed-off-by: Dietmar Maurer <dietmar at proxmox.com>
>> ---
>>   PVE/Storage/Plugin.pm | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/PVE/Storage/Plugin.pm b/PVE/Storage/Plugin.pm
>> index eab73f5..bd4bb8c 100644
>> --- a/PVE/Storage/Plugin.pm
>> +++ b/PVE/Storage/Plugin.pm
>> @@ -6,6 +6,7 @@ use warnings;
>>   use File::chdir;
>>   use File::Path;
>>   use File::Basename;
>> +use Time::Local qw(timelocal);
>>     use PVE::Tools qw(run_command);
>>   use PVE::JSONSchema qw(get_standard_option);
>> @@ -924,6 +925,11 @@ my $get_subdir_files = sub {
>>           my $format = $2;
>>           $info = { volid => "$sid:backup/$1", format => $format };
>>   +        if ($fn =~ m!^vzdump\-(?:lxc|qemu)\-(?:[1-9][0-9]{2,8})\-(\d{4})_(\d{2})_(\d{2})\-(\d{2})_(\d{2})_(\d{2})\.${format}$!) {
>> +        my $epoch = timelocal($6, $5, $4, $3, $2-1, $1 - 1900);
>> +        $info->{ctime} = $epoch;
>> +        }
> 
> would it not be 'better' if we use the ctime from patch 4/6?
> i guess its probably because of consistency of filename/time,
> but after 4/6 we already have the ctime and do not need to parse anything
> 
> also would be more correct since the api documentation (3/6) explicity says 'creation time'

the "issue" the is that you possibly see two different date/time stamps,
the one encoded in the name and the one from the file - which do not need
to match - AFFLICT, that's the reason for this extra parsing.





More information about the pve-devel mailing list