UNIX – Find Files that Changed Within Time Window

Every so often us lowly UNIX admins find ourselves needing to search a file system for files that have been created or changed within a certain time window. In other words, those files that are newer than time “X”, but not newer than time “Y”. There are a number of ways to accomplish this, but my preferred method is to create two reference files to indicate the beginning and end of my window and use the “-newer” and “! -newer” flags to search for files that changed within that window.

# touch -amt 200910260000 /tmp/starttime
# touch -amt 200910262359 /tmp/endtime
# find / -type f -newer /tmp/starttime -a ! -newer /tmp/endtime

The guys at virtuelvis.com point out that it is more elegant to accomplish this without creating two files, but their solution does not work with operating systems that use strict POSIX compliant “find” implementations, making it of little use in some cases. For the curious, here is their example:

# find . -type f -newermt 2009-10-26 ! -newermt 2009-10-27

Macintosh Finder Copy to Samba Share Problem

With the last Samba upgrade, we started having problems copying files to our Samba share from the Mac OSX finder.When attempting the copy we received an error reading: “The operation cannot be completed because you do not have sufficient privileges for some of the items.”

There were no permissions issues, which was substantiated by our unhindered ability to do UNIX copies to the same share, and the smb.conf file had not changed. After searching the groups and finding nothing of use, I set up a test environment with all the same versions and settings, and replicated the error.

Because the Samba share is mounted over NFS on the server, and because the Mac Finder creates that annoying place holder file before actually copying the real file, I suspected that the problem had something to do with file locking. With this in mind, I systematically turned off all Samba locks one by one until I found the ones that worked.

Finder Copy Error

Finder Copy Error

IMPORTANT NOTE: The Samba share point in this environment is mounted over NFS on the server. The error did not occur when the Samba share point was on a filesystem local to the server.

Here is what our share looked like before making the changes:

[your-directive]
read only = no
preserve case = yes
short preserve case = yes
csc policy = disable
share modes = no
level2 oplocks = no

Adding either of the two following directives resolved the problem:

locking = no
posix locking = no

Either one would have worked, but we ultimately decided to turn off posix locking because we wanted Samba to continue locking files for Windows connections, but stop locking them over NFS. Below is our share after making the change:

[your-share]
read only = no
preserve case = yes
short preserve case = yes
csc policy = disable
share modes = no
posix locking = no
level2 oplocks = no

The smb.conf man page has the following to say about posix locking:

posix locking
The smbd daemon maintains an database of file locks obtained by SMB clients. The default behavior is to map this internal database to POSIX locks. This means that file locks obtained by SMB clients are consistent with those seen by POSIX compliant applications accessing the files via a non-SMB method (e.g. NFS or local file access). You should never need to disable this parameter.

Default: posix locking = yes

The smb.conf man page has the following to say about locking:

locking
This controls whether or not locking will be performed by the server in response to lock requests from the client.

If locking = no, all lock and unlock requests will appear to succeed and all lock queries will report that the file in question is available for locking.

If locking = yes, real locking will be performed by the server.

This option may be useful for read-only filesystems which may not need locking (such as CDROM drives), although setting this parameter of no is not really recommended even in this case.
Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter.

No default

Hopefully this is helpful. If anyone has anything to add, please post a comment.