FINFO Function Generating Incorrect Last Modified Date

[cgates]

Hello, 

I'm using SAS 9.4 for this code on a Windows computer. A .bat file runs this program each morning and my first lines of code use finfo to find the last modified date of two csv files I'm importing. The csv files gets overwritten each morning prior to the SAS program running, so if the last modified date is not equal to today's date, I force the program to abort.

The issue is that the program has aborted twice now (not consecutively - once a week ago and this morning) because finfo generated an incorrect last modified date. This morning it says the csv files were last updated on Oct. 11th, but they were actually updated this morning on Oct. 12th. What could be causing this? Code below from this morning's run.

NOTE: PROCEDURE PRINTTO used (Total process time):
      real time           0.03 seconds
      cpu time            0.00 seconds
      
The SAS System             06:00 Monday, October 12, 2020
Engine:        V9 

filename fileref "J:\Tests.csv";  
filename filerefa "J:\Facilities.csv"; 
data a(drop=fidlab fidreg);                                                                                                                       
   infile fileref truncover obs=1;      
   infile filerefa truncover obs=1;    
   fidlab=fopen("fileref");   
   fidreg=fopen("filerefa");    
   moddatelab=input(finfo(fidlab,"Last Modified"),anydtdte32.);
   moddatereg=input(finfo(fidreg,"Last Modified"),anydtdte32.);
   format moddatelab moddatereg date9.;
   CALL SYMPUT("labtime",put(moddatelab,date9.)) ;
   CALL SYMPUT("regtime",put(moddatereg,date9.)) ; 
run;   


NOTE: The infile FILEREF is:
      Filename=J:\Tests.csv,
      RECFM=V,LRECL=32767,File Size (bytes)=2407224,
      Last Modified=11Oct2020:03:15:16,
      Create Time=15Sep2020:11:40:50

NOTE: The infile FILEREFA is:
      
      Filename=J:\Facilities.csv,
      RECFM=V,LRECL=32767,File Size (bytes)=41733,
      Last Modified=11Oct2020:03:17:01,
      Create Time=15Sep2020:11:41:54

However, when I check the filepath to see when the two csv files were last updated, this is what I see.

EDIT: Worth noting that the two csv files get updated each morning at 12:17 AM and 12:15 AM MST. The program is run on an EST computer so the 11Oct2020:03:17 and 11Oct2020:03:15 times are from yesterday's update to to the CSV files. I'm not sure why SAS picked up that one instead of this morning's modification.

[Kurt_Bremser]

You input a datetime, but SYMPUT it with a DATE format. That won't work, as dates are counts of days, and datetimes counts of seconds.

I would also refrain from using the ANYDTDTE informat, instead reading date and time separately, and force the proper informat for the date, in your case MMDDYY10.

Anyway, if SAS reports the modified timestamp as being from yesterday, that's what it gets from the filesystem. Are you sure you are looking at the same network share (the drive letter J lets me suspect that)?

[cgates]

Hi Kurt. I'm positive I'm looking at the same network share which is why I can't identify the root cause. This program has been running automated every day for the past 30 days and it has only aborted twice due to this issue. We've changed nothing in the code. After the 1st abort, we even set the automation to run a couple of hours later thinking maybe there wasn't enough time for SAS to pick up the new modified date. But here we are again.

[Mike_B · Accepted solution]

I too occasionally run into iffy moddates when I use SAS's file attribute functions--using base SAS on a Windows 10 machine accessing files on a Microsoft server (WIN 6.3.9600). By iffy I mean moddate < crdate. My kluge is to read in moddate and crdate and use whichever is greater. I agree that it would be better to use a datetime informat, though anydtdte32 worked in my test.

filename fileref "J:\Tests.csv";  
filename filerefa "J:\Facilities.csv"; 
data a(drop=fidlab fidreg);                                                                                                                       
   infile fileref truncover obs=1;      
   infile filerefa truncover obs=1;    
   fidlab=fopen("fileref");
   fidreg=fopen("filerefa");
   moddatelab=input(finfo(fidlab,"Last Modified"),datetime.);
   moddatereg=input(finfo(fidreg,"Last Modified"),datetime.);
   crdatelab=input(finfo(fidlab,"Create Time"),datetime.);
   crdatereg=input(finfo(fidreg,"Create Time"),datetime.);
   labdate=datepart(max(moddatelab,crdatelab));
   regdate=datepart(max(moddatereg,crdatereg));
   format moddatelab moddatereg crdatelab crdatereg datetime. labdate regdate date9.;
   CALL SYMPUTX("labtime",put(labdate,date9.)) ;
   CALL SYMPUTX("regtime",put(regdate,date9.)) ; 
run; 

[ErikLund_Jensen]

Hi @cgates ,@Mike_B 

"By iffy I mean moddate < crdate". This is normal Windows-behaviour when a file is copied. The copy gets a new creation-timestamp, but the modified-date is preserved from the original file. 

Now in this case it looks like the files are updated and not copied/recreated, because the creation-timestamp is a month back. But I would still accept the modified-timestamp as valid and look for errors in the update process. Update not scheduled to run on sundays?, file locked by weekly backup? or .....?