I want to write a script that recursively backs up all files in a
directory that haven't changed in, say 35 years.

Caveat: the directory is a vfat directory:

$ mount|grep sda6
/dev/sda6 on /home/oc/storage type vfat
(rw,relatime,uid=1000,gid=1000,fmask=0133,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

$ grep storage /etc/fstab
UUID=BD49-37B5 /home/oc/storage vfat uid=1000,gid=1000,fmask=133
0

$ find /home/oc/storage/Documents/ -type f -mtime -35|wc -l
190
$ find /home/oc/storage/Documents/ -type f -ctime -35|wc -l
795

I've checked the list of all files in option -mtime vs -ctime and in
both cases I've seen files that I am pretty sure I have never touched in
the last 35 days. Conservatively, I'd go for using the -mtime option,
but I wonder if the fact the partition is vfat may skew the results from
find.

--
Ottavio Caruso

On Sat, 08 May 2021 09:57:48 +0100, Ottavio Caruso wrote:

> I want to write a script that recursively backs up all files in a
> directory that haven't changed in, say 35 years.
>
> Caveat: the directory is a vfat directory:
>
> $ mount|grep sda6
> /dev/sda6 on /home/oc/storage type vfat
> (rw,relatime,uid=1000,gid=1000,fmask=0133,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
>
> $ grep storage /etc/fstab
> UUID=BD49-37B5 /home/oc/storage vfat uid=1000,gid=1000,fmask=133
> 0
>
> $ find /home/oc/storage/Documents/ -type f -mtime -35|wc -l
> 190
> $ find /home/oc/storage/Documents/ -type f -ctime -35|wc -l
> 795
>
> I've checked the list of all files in option -mtime vs -ctime and in
> both cases I've seen files that I am pretty sure I have never touched in
> the last 35 days. Conservatively, I'd go for using the -mtime option,
> but I wonder if the fact the partition is vfat may skew the results from
> find.

IIRC, the FAT filesystem (and the VFAT filesystem built on it) does not natively
support Unix mtime or ctime values. Indeed, the kernel documentation for the vfat
fs indicates that the vfat directory entry (the equivalent of a combined unix
directory entry /and/ a unix inode) can be described with the structure

struct directory { // Short 8.3 names
unsigned char name[8]; // file name
unsigned char ext[3]; // file extension
unsigned char attr; // attribute byte
unsigned char lcase; // Case for base and extension
unsigned char ctime_ms; // Creation time, milliseconds
unsigned char ctime[2]; // Creation time
unsigned char cdate[2]; // Creation date
unsigned char adate[2]; // Last access date
unsigned char reserved[2]; // reserved values (ignored)
unsigned char time[2]; // time stamp
unsigned char date[2]; // date stamp
unsigned char start[2]; // starting cluster number
unsigned char size[4]; // size of the file
};

Unix mtime reports the "time of last modification", while ctime reports the "time
of last inode modification", neither of which appear in a FAT directory entry.

I believe that Linux initially "fakes" the (V)FAT mtime and ctime values when retrieved
through a stat(2) call. At first, it can only use the vfat ctime or adate values
to create the faux mtime and ctime values (adate is close to, but not exactly, the
unix atime of the file, while the vfat cdate/ctime values have no stat(2) analogue).
However, as the vfat fs layer keeps a "shadow inode" entry for each vfat directory
entry, the vfat fs layer will update these faux mtime and ctime values with each
filesystem activity. Note that the faux mtime and ctime values are lost when the vfat
fs is umounted.

As to why you get inconsistant results when looking for mtimes and ctimes on vfat
filesystems, my /guess/ is that you are seeing the cumulative effects of these filesystem
compromises and translations, which are transient and activity dependant.

HTH
--
Lew Pitcher
"In Skills, We Trust"