Cfrtjryk

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.

best regards, Sala

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.

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.

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.