Sponsored Content
Top Forums Shell Programming and Scripting behavior of find utility's -mtime -7 primary Post 302967543 by Don Cragun on Wednesday 24th of February 2016 06:20:02 PM
Old 02-24-2016
When a file is created, its last data access timestamp, last data modification timestamp, and last status change timestamp are all marked for update. Any timestamps marked for update are required by the standards to be updated before a successful completion of any of the following functions/system calls on that file: fstat(), fstatat(), fsync(), futimens(), lstat(), stat(), utime(), utimensat(), or utimes().

While it would theoretically be possible for the istat and find utilities to read the i-nodes for the files they are processing directly from the disks on which the filesystems are located, any sane utility writer would use fstat() after getting the file's name from reading the directory being processed. And, since the fstat() is required to update the timestamps before returning the status information to the caller, what you are seeing from istat should not happen on a system that conforms to the standards. (Note, however, that some filesystems have options that can be used when they are mounted that make the filesystems "more responsive" by ignoring standard requirements. If the filesystem you're working in was mounted with one of these options, you might want to ask your system administrator to change the mount options used so your code will work correctly instead of working incorrectly slightly faster.)
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

find -mtime off by one day?

If I use the find command to find files older than n days I have to enter find . -mtime +(n-1). I tried this on a Solaris 9 system and also Linux. Is this something that all Unix veterans know about (I'm new to Unix)? If so, maybe my man pages need to be updated (how to do this?). :confused: (4 Replies)
Discussion started by: ceanntrean
4 Replies

2. UNIX for Dummies Questions & Answers

find . -mtime

...what am i doing wrong?? I need to find all files older than 30 days and delete but I can't get it to pull details for ANY + times. The file below has a time stamp which is older than 1 day, however if I try and select it using any of the -time flags it just doesn't see it. (the same thing... (1 Reply)
Discussion started by: topcat8
1 Replies

3. UNIX for Dummies Questions & Answers

problem with find and mtime

I am using HP-UNIX , The below command doesnt display anything although i have changed a file in the directory by toutch -t 200010101800 nfile find /tmp/transfer/ -name "*.*" -mtime +1 Any problrm with the find command i written . .Please help ??.. Thanks, Arun (4 Replies)
Discussion started by: arunkumar_mca
4 Replies

4. UNIX for Dummies Questions & Answers

find -mtime query

Hello everyone, I have got two queries: 1) I want to do some work on files that were last modified yesterday. Will find ... -mtime -2 be correct or -mtime-1? 2)What about finding files that were modified today? Will it be -mtime -0 or -mtime -1? Thanks. (1 Reply)
Discussion started by: Rajat
1 Replies

5. UNIX for Dummies Questions & Answers

(find) mtime vs. (unix) mtime

Hi I've made some test with perl script to learn more about mtime... So, my question is : Why the mtime from findfind /usr/local/sbin -ctime -1 -mtime -1 \( -name "*.log" -o -name "*.gz" \) -print are not the same as mtime from unix/linux in ls -ltr or in stat() function in perl : stat -... (2 Replies)
Discussion started by: hiddenshadow
2 Replies

6. UNIX for Dummies Questions & Answers

find mtime syntax

Hi guys, I am looking for a way of moving all files out of a directory with a time stamp greater then the one I specify. Can anyone suggest a way of doing so? For example, move all files out of dir1 which were created after 17:00 into dir2. Thanks :) (1 Reply)
Discussion started by: JayC89
1 Replies

7. Shell Programming and Scripting

Find + prune + mtime

Hi, i try to catch all files in a dir ,without going down in subdir , which don't have file extension and older than 10 days for example: my dir : drwxr-xr-x 7 notes01 notes 4096 Mar 8 14:11 . drwxr-xr-x 116 root system 4096 Mar 9 11:17 .. -rw-r----- 1 notes01... (4 Replies)
Discussion started by: Nicol
4 Replies

8. Shell Programming and Scripting

find -mtime +7

Dear all, find $ADMIN_DIR/$SID/arch/ -name '*.gz' -mtime +7 -exec rm {} \; is it retaining 7 days OR 8 days .gz files ? Thanks Prakash (10 Replies)
Discussion started by: prakashoracledb
10 Replies

9. UNIX for Dummies Questions & Answers

Find using mtime

Hi, so I was using mtime and its not behaving the way I would think its supposed too. I have two pdf files. One modified today and another 6 months ago. I upload them to the solaris server. Then I run the below find statements. This finds my 2 files find *.pdf -type f -name '*.pdf' this finds... (2 Replies)
Discussion started by: vsekvsek
2 Replies

10. Shell Programming and Scripting

Find by name and mtime

Hi, I'm trying to find all files that have a .ksh and .p extension and that are 7 days old by using the below find command but it doesn't seem to as expected. It gives me random results.. Can someone point out what may be wrong? find . -name "*.ksh" -o -name "*.p" -mtime -7 (2 Replies)
Discussion started by: Jazmania
2 Replies
UTIMENSAT(2)						     Linux Programmer's Manual						      UTIMENSAT(2)

NAME
utimensat, futimens - change file timestamps with nanosecond precision SYNOPSIS
#include <fcntl.h> /* Definition of AT_* constants */ #include <sys/stat.h> int utimensat(int dirfd, const char *pathname, const struct timespec times[2], int flags); int futimens(int fd, const struct timespec times[2]); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): utimensat(): Since glibc 2.10: _POSIX_C_SOURCE >= 200809L Before glibc 2.10: _ATFILE_SOURCE futimens(): Since glibc 2.10: _POSIX_C_SOURCE >= 200809L Before glibc 2.10: _GNU_SOURCE DESCRIPTION
utimensat() and futimens() update the timestamps of a file with nanosecond precision. This contrasts with the historical utime(2) and utimes(2), which permit only second and microsecond precision, respectively, when setting file timestamps. With utimensat() the file is specified via the pathname given in pathname. With futimens() the file whose timestamps are to be updated is specified via an open file descriptor, fd. For both calls, the new file timestamps are specified in the array times: times[0] specifies the new "last access time" (atime); times[1] specifies the new "last modification time" (mtime). Each of the elements of times specifies a time as the number of seconds and nanosec- onds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). This information is conveyed in a structure of the following form: struct timespec { time_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ }; Updated file timestamps are set to the greatest value supported by the filesystem that is not greater than the specified time. If the tv_nsec field of one of the timespec structures has the special value UTIME_NOW, then the corresponding file timestamp is set to the current time. If the tv_nsec field of one of the timespec structures has the special value UTIME_OMIT, then the corresponding file time- stamp is left unchanged. In both of these cases, the value of the corresponding tv_sec field is ignored. If times is NULL, then both timestamps are set to the current time. Permissions requirements To set both file timestamps to the current time (i.e., times is NULL, or both tv_nsec fields specify UTIME_NOW), either: 1. the caller must have write access to the file; 2. the caller's effective user ID must match the owner of the file; or 3. the caller must have appropriate privileges. To make any change other than setting both timestamps to the current time (i.e., times is not NULL, and neither tv_nsec field is UTIME_NOW and neither tv_nsec field is UTIME_OMIT), either condition 2 or 3 above must apply. If both tv_nsec fields are specified as UTIME_OMIT, then no file ownership or permission checks are performed, and the file timestamps are not modified, but other error conditions may still be detected. utimensat() specifics If pathname is relative, then by default it is interpreted relative to the directory referred to by the open file descriptor, dirfd (rather than relative to the current working directory of the calling process, as is done by utimes(2) for a relative pathname). See openat(2) for an explanation of why this can be useful. If pathname is relative and dirfd is the special value AT_FDCWD, then pathname is interpreted relative to the current working directory of the calling process (like utimes(2)). If pathname is absolute, then dirfd is ignored. The flags field is a bit mask that may be 0, or include the following constant, defined in <fcntl.h>: AT_SYMLINK_NOFOLLOW If pathname specifies a symbolic link, then update the timestamps of the link, rather than the file to which it refers. RETURN VALUE
On success, utimensat() and futimens() return 0. On error, -1 is returned and errno is set to indicate the error. ERRORS
EACCES times is NULL, or both tv_nsec values are UTIME_NOW, and either: * the effective user ID of the caller does not match the owner of the file, the caller does not have write access to the file, and the caller is not privileged (Linux: does not have either the CAP_FOWNER or the CAP_DAC_OVERRIDE capability); or, * the file is marked immutable (see chattr(1)). EBADF (futimens()) fd is not a valid file descriptor. EBADF (utimensat()) pathname is a relative pathname, but dirfd is neither AT_FDCWD nor a valid file descriptor. EFAULT times pointed to an invalid address; or, dirfd was AT_FDCWD, and pathname is NULL or an invalid address. EINVAL Invalid value in flags. EINVAL Invalid value in one of the tv_nsec fields (value outside range 0 to 999,999,999, and not UTIME_NOW or UTIME_OMIT); or an invalid value in one of the tv_sec fields. EINVAL pathname is NULL, dirfd is not AT_FDCWD, and flags contains AT_SYMLINK_NOFOLLOW. ELOOP (utimensat()) Too many symbolic links were encountered in resolving pathname. ENAMETOOLONG (utimensat()) pathname is too long. ENOENT (utimensat()) A component of pathname does not refer to an existing directory or file, or pathname is an empty string. ENOTDIR (utimensat()) pathname is a relative pathname, but dirfd is neither AT_FDCWD nor a file descriptor referring to a directory; or, one of the prefix components of pathname is not a directory. EPERM The caller attempted to change one or both timestamps to a value other than the current time, or to change one of the timestamps to the current time while leaving the other timestamp unchanged, (i.e., times is not NULL, neither tv_nsec field is UTIME_NOW, and nei- ther tv_nsec field is UTIME_OMIT) and either: * the caller's effective user ID does not match the owner of file, and the caller is not privileged (Linux: does not have the CAP_FOWNER capability); or, * the file is marked append-only or immutable (see chattr(1)). EROFS The file is on a read-only filesystem. ESRCH (utimensat()) Search permission is denied for one of the prefix components of pathname. VERSIONS
utimensat() was added to Linux in kernel 2.6.22; glibc support was added with version 2.6. Support for futimens() first appeared in glibc 2.6. ATTRIBUTES
For an explanation of the terms used in this section, see attributes(7). +------------------------+---------------+---------+ |Interface | Attribute | Value | +------------------------+---------------+---------+ |utimensat(), futimens() | Thread safety | MT-Safe | +------------------------+---------------+---------+ CONFORMING TO
futimens() and utimensat() are specified in POSIX.1-2008. NOTES
utimensat() obsoletes futimesat(2). On Linux, timestamps cannot be changed for a file marked immutable, and the only change permitted for files marked append-only is to set the timestamps to the current time. (This is consistent with the historical behavior of utime(2) and utimes(2) on Linux.) If both tv_nsec fields are specified as UTIME_OMIT, then the Linux implementation of utimensat() succeeds even if the file referred to by dirfd and pathname does not exist. C library/kernel ABI differences On Linux, futimens() is a library function implemented on top of the utimensat() system call. To support this, the Linux utimensat() sys- tem call implements a nonstandard feature: if pathname is NULL, then the call modifies the timestamps of the file referred to by the file descriptor dirfd (which may refer to any type of file). Using this feature, the call futimens(fd, times) is implemented as: utimensat(fd, NULL, times, 0); Note, however, that the glibc wrapper for utimensat() disallows passing NULL as the value for pathname: the wrapper function returns the error EINVAL in this case. BUGS
Several bugs afflict utimensat() and futimens() on kernels before 2.6.26. These bugs are either nonconformances with the POSIX.1 draft specification or inconsistencies with historical Linux behavior. * POSIX.1 specifies that if one of the tv_nsec fields has the value UTIME_NOW or UTIME_OMIT, then the value of the corresponding tv_sec field should be ignored. Instead, the value of the tv_sec field is required to be 0 (or the error EINVAL results). * Various bugs mean that for the purposes of permission checking, the case where both tv_nsec fields are set to UTIME_NOW isn't always treated the same as specifying times as NULL, and the case where one tv_nsec value is UTIME_NOW and the other is UTIME_OMIT isn't treated the same as specifying times as a pointer to an array of structures containing arbitrary time values. As a result, in some cases: a) file timestamps can be updated by a process that shouldn't have permission to perform updates; b) file timestamps can't be updated by a process that should have permission to perform updates; and c) the wrong errno value is returned in case of an error. * POSIX.1 says that a process that has write access to the file can make a call with times as NULL, or with times pointing to an array of structures in which both tv_nsec fields are UTIME_NOW, in order to update both timestamps to the current time. However, futimens() instead checks whether the access mode of the file descriptor allows writing. SEE ALSO
chattr(1), touch(1), futimesat(2), openat(2), stat(2), utimes(2), futimes(3), inode(7), path_resolution(7), symlink(7) COLOPHON
This page is part of release 4.15 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/. Linux 2017-09-15 UTIMENSAT(2)
All times are GMT -4. The time now is 08:45 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy