I am wondering if there are in linux file systems supporting for each file the 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 community
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
$ 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.
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
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
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.
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.