3

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.

10

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.

  • Gilles, I am eager and liked this answer. To be honest, there isn't one that fullfill my objective : an absolute value ( not depending on comparing with other values, like dates ) modified by the OS internals, each and every time the file is modified. I fear custom file attribs not handling the "flip state on modify". Can you please explain ? – Massimo Aug 20 '16 at 15:52
  • @Massimo Use the file's timestamp? If the file is modified then the copy in the extended attribute won't match the actual timestamp anymore. Do note that it's common for modified files to be replaced by a new file, rather than overwritten; in that case the new file won't have the custom attribute. – Gilles Aug 20 '16 at 19:17
  • 1
    This answer seems to completely miss the fact that the archive file attribute has "magic" behavior, which you cannot do with a custom attribute. – Jasper Nov 22 '18 at 11:54
  • @Jasper The custom attribute does not have the same magic behavior, but as I explain in my answer, it's close enough for the purpose of knowing what to back up, if the backup tool does some work which is different from “set the attribute”. – Gilles Nov 23 '18 at 21:23
  • this is great, just what I needed. The 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. – papo Dec 16 '18 at 20:39
1

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.

  • The atime is often not updated on every access. Compare noatime and relatime (the latter of which I believe is the default these days) mount options. – a CVn Aug 20 '16 at 19:27
0

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.

  • Btrfs and ext4 also support custom attributes. Why would this be inefficient? – Gilles Aug 18 '16 at 0:14
  • It may not be a lot, but it implies an additional system call for the extended attribute, and the data retrieved needs to be parsed since it's a string instead of an int. – Julie Pelletier Aug 18 '16 at 0:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.