Bug #128243 for File-Touch: File:Touch & make

Mon Jan 14 14:48:36 2019 BIGFOOT [...] cpan.org - Ticket created

Subject:

File:Touch & make

In creating a script that is required to prevent a make from happening by "touching" a file AFTER another process has updated dependency I noticed that using File::Touch does not give the intended result. Moreover it appears that the file system actually maintains greater granularity of time for modification of files. Consider these two files: [rlauer@ip-10-1-4-191 lambda](cpanfile)$ stat Lambda File: ‘Lambda’ Size: 759 Blocks: 8 IO Block: 4096 regular file Device: ca01h/51713d Inode: 718847 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 501/ rlauer) Gid: ( 501/ rlauer) Access: 2019-01-14 14:32:58.000000000 -0500 Modify: 2019-01-14 14:32:58.000000000 -0500 Change: 2019-01-14 14:32:58.278280121 -0500 Birth: - [rlauer@ip-10-1-4-191 lambda](cpanfile)$ stat runtime_layer_arn File: ‘runtime_layer_arn’ Size: 61 Blocks: 8 IO Block: 4096 regular file Device: ca01h/51713d Inode: 718761 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 501/ rlauer) Gid: ( 501/ rlauer) Access: 2019-01-14 14:32:58.274280108 -0500 Modify: 2019-01-14 14:32:58.274280108 -0500 Change: 2019-01-14 14:32:58.274280108 -0500 Birth: - Note that Lambda was actually touched by File::Touch AFTER runtime_layer_arn... It appears to me that File::Touch granularity cannot be relied upon for make operations. Perhaps not a bug, but an implementation anomaly? Modification of file attributes vs actual modification or access by the file system? If my analysis is correct than perhaps a note in documentation might be warranted that the granularity may not match actual file system operations and therefore mod/access times do not reflect the actual time but a truncated to the second time.

Fri Nov 29 09:33:46 2019 SREZIC [...] cpan.org - Correspondence added

On 2019-01-14 14:48:36, BIGFOOT wrote: Show quoted text

> In creating a script that is required to prevent a make from happening > by "touching" a file AFTER another process has updated dependency I > noticed that using File::Touch does not give the intended result. > Moreover it appears that the file system actually maintains greater > granularity of time for modification of files. Consider these two > files: > > [rlauer@ip-10-1-4-191 lambda](cpanfile)$ stat Lambda > File: ‘Lambda’ > Size: 759 Blocks: 8 IO Block: 4096 regular > file > Device: ca01h/51713d Inode: 718847 Links: 1 > Access: (0664/-rw-rw-r--) Uid: ( 501/ rlauer) Gid: ( 501/ > rlauer) > Access: 2019-01-14 14:32:58.000000000 -0500 > Modify: 2019-01-14 14:32:58.000000000 -0500 > Change: 2019-01-14 14:32:58.278280121 -0500 > Birth: - > > [rlauer@ip-10-1-4-191 lambda](cpanfile)$ stat runtime_layer_arn > File: ‘runtime_layer_arn’ > Size: 61 Blocks: 8 IO Block: 4096 regular > file > Device: ca01h/51713d Inode: 718761 Links: 1 > Access: (0664/-rw-rw-r--) Uid: ( 501/ rlauer) Gid: ( 501/ > rlauer) > Access: 2019-01-14 14:32:58.274280108 -0500 > Modify: 2019-01-14 14:32:58.274280108 -0500 > Change: 2019-01-14 14:32:58.274280108 -0500 > Birth: - > > Note that Lambda was actually touched by File::Touch AFTER > runtime_layer_arn... > > It appears to me that File::Touch granularity cannot be relied upon > for make operations. Perhaps not a bug, but an implementation > anomaly? Modification of file attributes vs actual modification or > access by the file system? If my analysis is correct than perhaps a > note in documentation might be warranted that the granularity may not > match actual file system operations and therefore mod/access times do > not reflect the actual time but a truncated to the second time.

Standard perl's utime() cannot do sub-second granularity, except if called with an explicit undef for both atime and mtime arguments. In this case the current timestamp is used automatically, and it seems that in this case sub-second granularity is used (checked on a Ubuntu 16.04 system). Another possibility is to use the high resolution utime() from Time::HiRes. It seems that it's enough to do the following change: diff --git i/lib/File/Touch.pm w/lib/File/Touch.pm index b71b0c1..41f63e4 100644 --- i/lib/File/Touch.pm +++ w/lib/File/Touch.pm @@ -12,6 +12,7 @@ use Carp; use IO::File; use File::stat; use Fcntl; +use Time::HiRes qw(time utime); my $SYSOPEN_MODE = O_WRONLY|O_CREAT; eval { Checking with perl -Ilib -MFile::Touch -e 'touch("/tmp/bla"); system("stat /tmp/bla")' shows that atime+mtime are now with high resolution. (If someone needs a formal PR, then I can do one)

Fri Nov 29 09:33:47 2019 The RT System itself - Status changed from 'new' to 'open'

Tue Apr 28 03:40:58 2020 SVW [...] cpan.org - Correspondence added

Am Fr 29. Nov 2019, 09:33:46, SREZIC schrieb: Show quoted text

> On 2019-01-14 14:48:36, BIGFOOT wrote:

> > In creating a script that is required to prevent a make from > > happening > > by "touching" a file AFTER another process has updated dependency I > > noticed that using File::Touch does not give the intended result. > > Moreover it appears that the file system actually maintains greater > > granularity of time for modification of files. Consider these two > > files: > > > > [rlauer@ip-10-1-4-191 lambda](cpanfile)$ stat Lambda > > File: ‘Lambda’ > > Size: 759 Blocks: 8 IO Block: 4096 regular > > file > > Device: ca01h/51713d Inode: 718847 Links: 1 > > Access: (0664/-rw-rw-r--) Uid: ( 501/ rlauer) Gid: ( 501/ > > rlauer) > > Access: 2019-01-14 14:32:58.000000000 -0500 > > Modify: 2019-01-14 14:32:58.000000000 -0500 > > Change: 2019-01-14 14:32:58.278280121 -0500 > > Birth: - > > > > [rlauer@ip-10-1-4-191 lambda](cpanfile)$ stat runtime_layer_arn > > File: ‘runtime_layer_arn’ > > Size: 61 Blocks: 8 IO Block: 4096 regular > > file > > Device: ca01h/51713d Inode: 718761 Links: 1 > > Access: (0664/-rw-rw-r--) Uid: ( 501/ rlauer) Gid: ( 501/ > > rlauer) > > Access: 2019-01-14 14:32:58.274280108 -0500 > > Modify: 2019-01-14 14:32:58.274280108 -0500 > > Change: 2019-01-14 14:32:58.274280108 -0500 > > Birth: - > > > > Note that Lambda was actually touched by File::Touch AFTER > > runtime_layer_arn... > > > > It appears to me that File::Touch granularity cannot be relied upon > > for make operations. Perhaps not a bug, but an implementation > > anomaly? Modification of file attributes vs actual modification or > > access by the file system? If my analysis is correct than perhaps a > > note in documentation might be warranted that the granularity may not > > match actual file system operations and therefore mod/access times do > > not reflect the actual time but a truncated to the second time.

> > Standard perl's utime() cannot do sub-second granularity, except if > called with an explicit undef for both atime and mtime arguments. In > this case the current timestamp is used automatically, and it seems > that in this case sub-second granularity is used (checked on a Ubuntu > 16.04 system). > > Another possibility is to use the high resolution utime() from > Time::HiRes. It seems that it's enough to do the following change: > > diff --git i/lib/File/Touch.pm w/lib/File/Touch.pm > index b71b0c1..41f63e4 100644 > --- i/lib/File/Touch.pm > +++ w/lib/File/Touch.pm > @@ -12,6 +12,7 @@ use Carp; > use IO::File; > use File::stat; > use Fcntl; > +use Time::HiRes qw(time utime); > > my $SYSOPEN_MODE = O_WRONLY|O_CREAT; > eval { > > Checking with > > perl -Ilib -MFile::Touch -e 'touch("/tmp/bla"); system("stat > /tmp/bla")' > > shows that atime+mtime are now with high resolution. > > (If someone needs a formal PR, then I can do one)

I guess PR means Pre-Release. I don't know the difference between a "formal PR" and an official new release of this module, but I would appreciate a new release.