Skip to content

[R-pkg-devel] Failed: Future File Timestamp Check

10 messages · Jeff Newmiller, Josiah Parry, Duncan Murdoch +4 more

Original
Josiah Parry
# 
I'm running R CMD check for my package {calcite} (source:
https://github.com/r-arcGIS/calcite) which is failing due to what *looks* like
a bug.

R CMD check fails at "checking for future file timestamps"

I get this error:  ...Error in if (abs(unclass(now_local) -
unclass(now)[1]) > 300) missing value where TRUE/FALSE needed.

It seems that an NA is being generated somehow during this check but I'm
unsure how.

One thing that comes to mind is that the file that contains all of my
function definitions is generated using writeLines() but the output of `
file.info()` looks normal to me.

Have others encountered this? I'm on R 4.4.0 Puppy Cup

platform       aarch64-apple-darwin20
arch           aarch64
os             darwin20
system         aarch64, darwin20
status
major          4
minor          4.0
year           2024
month          04
day            24
svn rev        86474
language       R
version.string R version 4.4.0 (2024-04-24)
nickname       Puppy Cup
Jeff Newmiller
# 
Packages are supposed to work when mounted in a read-only filesystem... using writeLines seems like a very bad idea since you can't assume the package install is writeable when it is run, and running code from tmp is a security hole.

If you absolutely cannot think of a way around running code from generated files, then maybe you should use textConnection to run from internal RAM.
On February 4, 2025 1:11:10 PM PST, Josiah Parry <josiah.parry at gmail.com> wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Josiah Parry
    

    

      
      #
    

  


  

      
The file was written using writeLines() but it is just a normal R script
with normal function definitions and is included in the R/ directory. The
source code is just programmatically generated.


On Tue, Feb 4, 2025 at 14:54 Jeff Newmiller <jdnewmil at dcn.davis.ca.us>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Jeff Newmiller
    

    

      
      #
    

  


  

      
That was clear to me, and changes nothing about my comments.

        
On February 4, 2025 3:27:34 PM PST, Josiah Parry <josiah.parry at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
One question is when that file is produced.  Do you produce it before 
preparing the tarball, or is it produced as part of the installation 
process?

Duncan Murdoch

        
On 2025-02-04 6:27 p.m., Josiah Parry wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Josiah Parry
    

    

      
      #
    

  


  

      
Thanks, Duncan!

It is produced before preparing the tarball. It?s just a way to automate
defining many 100ish  functions that have the same structure.  l run the
script manually when I want to update definitions.

There is not any auto-magical process that creates a file before the build
or install step. This would be the equivalent of something like running the
following once during the development process

writeLines(?hello_world <- function() { ?Hello, world!? }?,
?R/hello-world.R?)


On Tue, Feb 4, 2025 at 17:19 Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Josiah,

that test tests the accuracy of the system clock by querying https://worldtimeapi.org/api/timezone/etc/UTC so my guess would be that you have either network or proxy issues which cause that request to fail by providing garbage instead of the actual response. 

The call to test yourself is

            

      
      
      
    

        
[1] "{\"utc_offset\":\"+00:00\",\"timezone\":\"Etc/UTC\",\"day_of_week\":3,\"day_of_year\":36,\"datetime\":\"2025-02-05T01:42:19.272728+00:00\",\"utc_datetime\":\"2025-02-05T01:42:19.272728+00:00\",\"unixtime\":1738719739,\"raw_offset\":0,\"week_number\":6,\"dst\":false,\"abbreviation\":\"UTC\",\"dst_offset\":0,\"dst_from\":null,\"dst_until\":null,\"client_ip\":\"121.98.39.155\"}"

It has to have the "datetime" entry. If you can't fix your network you can skip that test with

_R_CHECK_FUTURE_FILE_TIMESTAMPS_=FALSE

Cheers,
Simon

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
2 days later

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

          

      
      
      
    

        
I'm quite sure that is overridden 'R CMD check' when using the
--as-cran flag. The workaround that I have found is to set environment
variable:

_R_CHECK_SYSTEM_CLOCK_=FALSE

I have observed <http://worldtimeapi.org/api/timezone/etc/UTC> timing
out a lot over the last couple of months from several different
networks and hosts. I've seen it happen in the past too (last couple
of years), but it has got considerably worse recently. Maybe they're
throttling in per IP(?). I consider it quite unreliable these days, so
I use _R_CHECK_SYSTEM_CLOCK_=FALSE by default now.

/Henrik

On Tue, Feb 4, 2025 at 5:50?PM Simon Urbanek

        
<simon.urbanek at r-project.org> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Greg Hunt
    

    

      
      #
    

  


  

      
Does all this mean that the check is not handling its own errors?

On Sat, 8 Feb 2025 at 8:28?AM, Henrik Bengtsson <henrik.bengtsson at gmail.com>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Michael Chirico
    

    

      
      #
    

  


  

      
Actually, it looks like R CMD check has _intended_ to just skip in the
case the website is misbehaving:

https://github.com/r-devel/r-svn/blob/3578a3f858136a8abcd2f708f38a8dff6225ec42/src/library/tools/R/check.R#L549-L552

My guess is this test should be improved, currently we get (logical)
NA if the read throws an error, but not if the API returns but in an
unexpected format:

identical(as.POSIXct(NA), NA)
# [1] FALSE

I filed a bug & patch:

https://bugs.r-project.org/show_bug.cgi?id=18852

        
On Fri, Feb 7, 2025 at 1:54?PM Greg Hunt <greg at firmansyah.com> wrote: