I am wondering if there are in linux file systems supporting for each file the archive bit
https://en.m.wikipedia.org/wiki/Archive_bit
I need something with the same logic in native f.s., like ext3, not fat neither ntfs.
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this communityI am wondering if there are in linux file systems supporting for each file the archive bit
https://en.m.wikipedia.org/wiki/Archive_bit
I need something with the same logic in native f.s., like ext3, not fat neither ntfs.
Linux doesn't have an exact equivalent of the DOS/Windows archive bit, but you can make something similar. Modern Linux systems support custom file attributes, at least on ext4 and btrfs. You can use getfattr
to list them and setfattr
to set them. Custom attributes are extended attributes in the user namespace, i.e. with a name of that starts with the five characters user.
.
$ touch foo
$ getfattr foo
$ setfattr -n user.archive -v "$(date +%s -r foo)" foo
$ getfattr -d foo
# file: foo
user.archive="1471478895"
You can use a custom attribute if you wish. The value can be any short string (how much storage is available depends on the filesystem and on the kernel version; a few hundred bytes should be fine). Here, I use the file's timestamp; a modification would update the actual timestamp but not the copy in the custom attribute.
Note that if the file is modified by deleting it and replacing it with a new version, as opposed to overwriting the existing file, the custom attributes will disappear. This should be fine for your purpose: if the attribute is not present then the file should be backed up.
Incremental backup programs in the Unix world don't use custom attributes. What they do is to compare the timestamp of the file with the timestamp of the backup, and back up the file if it's changed. This is more reliable because it takes the actual state of the backup into account — backups made solely according to the system state are more prone to missing files due to a backup disappearing or due to mistakes made when maintaining the attribute.
date -r foo
caused error (spaces), quoting the subshell "$()" helps, but I would suggest use of epoch time setfattr -n user.archive -v $(date -r foo +%s) foo
, I would than expect this to be prone against time zone and summer/winter time changes, also server or server locale settings changes. Secondly, @Gilles, could you add right on top of your answer something like "There is no archive bit, but..." I did get confused for a bit, thought user.archive IS the archive bit.
No, There is not (directly).
Linux/Unix native filesystems maintain several timestamps per file (at least the last modified time mtime
, inode change time ctime
, and last accessed (or read) time atime
. The standard backup utilities primarily look at the mtime
timestamp to determine the last time a file changed in order to determine whether to include a given file in an incremental backup. This is more flexible than an archive bit, because backup systems can run an incremental backup against any full backup by simply comparing the mtime
for each file to the timestamp of the full backup.
If you are specifically looking for the behavior of the archive bit because you are going to use it for something other than calculating incremental backup file sets, you'll need to give more details about what you are trying to accomplish.
That said, you can simulate the behavior of an archive bit using the mtime
timestamp, because you can set the mtime
stamp from the command line or from your own program. For example, suppose you define for your purposes that an mtime
of 0
(UNIX "epoch") means the same as the archive bit being clear. Then, if the file is modified, the operating system will set the mtime
to the timestamp of the most recent modification (and so mtime
will no longer be 0
, which you can interpret as if the archive bit had been set).
You can set the mtime
from a shell script using touch
(see man touch
), and many shell tools like find
support searching using mtime
. From your own program in C or some other language, start with the stat(2) and utimes(2) man pages.
noatime
and relatime
(the latter of which I believe is the default these days) mount options.
There is no such attribute on Linux file systems. XFS supports custom attributes but that would be very inefficient to use in a backup.
The common solution is to rely on file modification time (mtime
). Doing an incremental backup is merely to archive those files that have a mtime
greater than the last backup time.