I think the initial thought was to protect against empty files being generated from Traffic Ops. However, over time that code has potentially been shifted some, and that is no longer the functionality. :)
So, yes, I think we could skip that check for files already on disk. On Tue, Jan 3, 2017 at 12:57 AM, Jifeng Yang (jifyang) <[email protected]> wrote: > Hi, > > We met a problem about traffic_ops_ort: > > The ATS config file “remap.config” happened to be zero size. After that, > the “remap.config” file couldn't be updated by the traffic_ops_ort. > > Checking the code in the file “/opt/ort/traffic_ops_ort.pl”, there is: > > sub can_read_write_file { > my $filename = shift; > ...... > if ( -z $file ) { > ( $log_level >> $ERROR ) && print "ERROR $file has > size=0!\n"; > $cfg_file_tracker->{$filename}->{'audit_failed'}++; > return 0; > } > ...... > return 1; > } > > By the code, the zero size file isn't treated as can_read_write_file. > > Can we treat zero size file as can_read_write_file? Is there any > consideration about this? > > The configuration file may become zero size file by some reason (such as > by accident). If zero size config file isn't treated as > can_read_write_file, it can't be updated any more if a configuration file > becomes zero size. > > Thanks, > Jifeng >
