Take the 2-minute tour ×

Does anyone know whether there is a command in linux that can set attributes to file so that the file can disappear after certain time. For example, if I set one attribute to file as "1/1/2015", so the file will delete itself at that time. Or is there any other ways to make this file become an accessible after some time? For example, I can set password to the file and after some time, the password will get expired and be a new password and the file will not be read any more.

I know in my own computer, I can set like cron tasks. But I just want to know if I send this file to others, the file can delete itself or make itself unreadable automatically.

share|improve this question
You want the attributes to follow your file when you send it to someone else? –  terdon Mar 4 at 19:56
This isn't possible. –  slm Mar 5 at 0:30
If this idea is inspired by snapchat, keep in mind that snapchat works in a very restricted set of contexts requiring software compliance at the other end. However, a standalone file is just a sequence of bits -- which is exactly the same thing as a sequence of numbers or letters. Now consider: "How can I write a series of numbers/letters such that it will cease to exist at a certain future point in time?" Short of magic, you absolutely cannot. As in, physically impossible (by which I mean, this would require violating the laws of physics). NO –  goldilocks Mar 5 at 2:41

6 Answers 6

Data that self-destructs is a farce. This is something only achievable in Hollywood movies.

You can limit access to resources over which you have control, but if a resource is available for any amount of time, you might as well assume that it has been copied and will be available on some other system.

share|improve this answer

UNIX inodes (nor any set of extended ACLs I am aware of) do not have a "last possible time to access" field. There are three timestamps in a UNIX inode (keep notes, because I have twice had this asked to me during job interviews):

  • ctime. In Windows, this is the "creation time". In UNIX, this is the last time the inode information for the file has been changed.
  • atime. The last time the file was accessed. Since it can slow things down to perform a disk write every time a file is read, there is a mount option in modern Linux distributions called "relative atime" which minimizes how often this information is updated.
  • mtime. The last time the file's contents have been changed

And, oh, an inode is a thingy in UNIX filesystems which has information about a file (its permissions, time stamps, where the file is on the hard disk, etc.)

So, to summarize, since there isn't a "ltime" (last time someone is allowed to access a file) field in inodes, this can not be set. A workaround would be to have a crontab that either deletes a file at a particular time or changes a file's permissions so it can no longer be read.

share|improve this answer

Doesn't make much sense what you say, if the recipient can read a file at a certain point he could make a copy and he won't need further access to the original resource as it's read only as you said. Other than that as an elaborated solution you may consider to wrap the resource with some software providing cryptographic tokens like Hasp keys etc.

share|improve this answer

If the recipient can see the contents once, they certaily can make a copy to stash away and forget the whole "self-destruct in 50 seconds" nonsense. That is independent of if the file just lives on this single system or is shipped around, if you need a key to read it, whatever.

share|improve this answer

What you're describing is essentially a DRM for UNIX/Linux systems.
DRM is usually implemented by encrypting the file and having a central system to manage the delivery of decryption keys according to set parameters, but the software that decrypts the content can usually get hacked to allow for saving of the unencrypted version when it decrypts it.

MPAA, the DVD consortium and lots of others have tried to make a bullet-proof DRM and failed, so I don't think there is hope to do this.

share|improve this answer

In snapchat, this (sort of) works because the file is received and deleted by an application and never actually viewed from the filesystem (never stored). It's more like an image in a webpage that "disappears" when you close the browser. If it is a general purpose file, it's meant to be copied, saved, and so on. It would need to be executable to even do anything to itself, and it would need to run at the time (which is unlikely). It may not even have a permission to delete itself.

Moreover, even in snapchat and similar tricks, it's just harder, not impossible, to copy the file. An image can be grabbed from the screen, any temporary file could be copied before deletion, and anything that is in RAM can be just grabbed and stored somewhere, you just need to know where it is. Even with encription (remember DRM), you can intercept the file when it is decoded (harder if this happens inside a display instead of computer, but still not impossible).

In short, this is virtually impossible, goes against the concept and purpose of a file, and all the hacks would need to be very dirty and easily circumventable.

share|improve this answer

Your Answer


