What's the point of the touch command? I know I can create empty files with it, but so is also the case with echo -n.

Otherwise, why would someone need to change the timestamps of a file? Unless to create the false impression about the age of a file, I don't see any other use, and this one is not a legitimate one (from my point of view).

Unless to create the false impression about the age of a file. Not necessary false impression. What if you want to change the modification time? It can be useful in scripts. This script heavily depends on the touch command and it is very convenient and simple to have it like that.
–
NikolayJan 13 '14 at 2:01

6

Consider what tar (or other de-archivers) do when they extract an archive. Generally they set the modification time of the file to the time from the archive, not the time the archive was extracted, and this is a desirable feature. Since it's legitimate for a user-mode program to create false timestamps there's not much argument why touch (or some other command-line program) shouldn't allow it based on a command-line argument. Learning C doesn't make you more legitimate than someone writing a sh script ;-)
–
Steve JessopJan 13 '14 at 2:14

5

In unix, there is no timestamp that describes the age of a file. That would be a creation timestamp and there is no such timestamp for files in unix.
–
Kevin FeganJan 13 '14 at 2:21

15 Answers
15

One advantage of touch is that it can specify arbitrary timestamps, while echo -n will always result in the current time.

An example of a legitimate use is to update a timestamp of a source code file so a program like make will consider the source file newer than its compiled object and rebuild it.

Other uses are to create files that function solely based on their existence e.g. /etc/nologin, which disallows logins if it exists. I'd also argue that touch myfile is a simpler construct than echo -n >> myfile, as well as being shorter to type.

another common use: touch a file to a specific date, then "find / -newer /the/file" to find all files changed/created after it
–
Olivier DulacJan 13 '14 at 9:47

@casey When I checked the documentation of echo -n I see that it says "do not output the trailing newline". So I do not see how can this create an empty file. Can you clarify please?
–
GeekJan 13 '14 at 16:03

2

@Geek echo -n will output an empty string, and by itself does nothing. Redirecting its output via >> causes the empty output to be appended to a file. The redirection will cause the file to be created if the file does not exist.
–
caseyJan 13 '14 at 16:07

5

That doesn't work: opening an existing file for output, but not writing to it, does not change the mtime (on my system, anyway). Even if it did, you don't need and shouldn't use echo -n for a command that does nothing. echo -n may output the string "-n" under some shells. If you really need a command that does nothing, : or true are a better option, but >> myfile by itself is also a perfectly valid way of creating the file if it doesn't exist. All this, of course, supports your answer that you should just use "touch".
–
hvdJan 13 '14 at 17:56

The underlying system call (utime) is important for various utilities like tar to be able to set the timestamps of a newly copied (un-tarred) file. Some backup utilities can also be optioned to reset the last-accesstime of files that they have copied.

One legitimate use of touch is to create a file with a particular timestamp. Such a "reference" file can then be used by commands like find. For example, to find all files more recently modified than Nov 1, 2013 (ie 2013/11/01)"

How to calculate that 201311010000 means Nov1,2013? Is there a utility which will tell me this? In other words how do I determine the input to touch?
–
GeekJan 13 '14 at 16:26

4

@Geek By looking at the number and noting that the first part, 20131101, can be broken down into 2013-11-01, or November 1, 2013. You can then assume that the 0000 part indicates a specific time of day, in this case 00 hours, 00 minutes. Or you could just look at the man page for touch, which tells you exactly what the format is (see -t).
–
JABJan 13 '14 at 16:32

NOTE: The total 0 output from ls -l is correct. This implementation of ls shows the number of blocks being used by the files when they're listed. You can assure yourself of this fact by adding the -s switch to ls. This will list the blocks in use by each file. Here I've added 2 characters to file1 & file2.

@sim: my question implies that I know that touch is for changing timestamps. I just wanted to know why would an honest user want that. If it were not for the ctime part of your answer, I'd had given you a -1.
–
Quora FeansJan 12 '14 at 19:46

16

@QuoraFea - my answer is for your benefit and ever user that ever comes across it in the future. Please don't assume that an answer is purely for your sake and I'm sorry if I offended you in any way, it was not my intent, I was merely attempting to explain the underpinnings of how time works.
–
slm♦Jan 12 '14 at 20:00

@sim: I'm not offended, just thought the answer was not going in the right direction. Anyway, thanks for this answer.
–
Quora FeansJan 12 '14 at 20:36

@Geek - try the commands. That is correct output from ls -l in a directory where the files have 0 size, and nothing else exists yet. As soon as you give one of the files size then the total will show up w/ the amount of blocks in use by the files. See my updates if you're unsure, I've added an example.
–
slm♦Jan 13 '14 at 17:12

Apart from the other two very good answers you got, yet another use is, in your words, to

create the false impression about the age of a file

for example for use in backup schemes. You might want to not update a backup with a newer one since they're identical, or since the changes are irrelevant compared to the expense of updating a backup on, say, a slow line to a remote host. To achieve this, you have the simple option of marking the backup file with a newer timestamp, not faking but declaring that the validity timestamp of that file is now a different one.

The impression about the age of the file is now indeed false, but its meaning is real and legitimate.

One of the most common uses of touch is -- or at least used to be -- to trigger a rebuild of code.

The usual build tools -- make and its derivitives -- try to save work by not recompiling/rebuilding files unless one of the files which went into creating them has changed -- for example, if a .o file is more recent than the .c source, it's usually safe to presume that the C source hasn't been changed since being compiled to produce that object file.

But there are times when you want to force something to be rebuilt. You could make a needless modification to one of its source files, but that risks accidentally damaging something. Instead, you could simply touch the file, making it look new without any risk of altering its content -- and that would be enough to convince make that it was time to rebuild everything that depends on that file.

While it seams a good idea to change a file to cause a rebuild I would argue against it. Some source code revision systems can get confused about a changed file. So touch is as bad as a manual change. To cause a rebuild I suggest deleting the output files .o of the source in question.
–
harperJan 13 '14 at 6:46

1

Manual changes and removal of the .o files both require more time and typing, and a manual change is much more error-prone. And we're only talking about modifying the timestamp on a working copy -- if edits are made afterward, the file will correctly reflect the change timestamp. And not all version control systems are confused by a timestamp.
–
DavidJan 13 '14 at 14:18

1

As David said. This really was standard Unix practice not that long ago, and still remains standard practice for developers working outside IDEs.
–
keshlamJan 13 '14 at 15:24

An important difference vs. things like echo (or the even better > file as mentioned by others) is that touch will not smash the contents. > file will empty a file. touch will not. Instead of thinking of tricks to avoid content damage, just use touch! It will do less work in the kernel anyway, because it will work only with the attributes of the file without wasting time actually preparing for an open and then performing a close.

Touch can probably alter the timestamp even if the file is currently under a mandatory or advisory lock, or an exclusive open. Hmmm, have never tested that or read up about it...

I considered mentioning that, but it's getting even more into side-effect territory. You'd also have to mention the fact that it would throw an error if the file happened to be exclusive-opened already, etc etc etc. A problem that could apply through the use of > too. I guess my secondary point - beyond the primary one that it's marginally quicker to merely touch the file's stats - is that it's a good idea to write code that tells it straight, instead of beating around the bush.
–
Guru AdrianJan 20 '14 at 5:55

Here is one - I use a software program called SageTV to record TV shows - these are often recorded in MPEG-2 which isn't a very efficient codec, it also isn't iPad/iPhone friendly. So I convert the files to .mp4 files. But when playing back the files SageTV expects the timestamp of the file to be when the TV show started - if not it screws up the timeline of the show so that it isn't easy to FF or REW. Therefore I use touch to reset the timestamp of the .mp4 file to be the same as the orignal file.
Is that legit?

Often you may have a process that changes from userid, like from root -> something else. Touch can give you the chance to create a file in a place that only root can touch before the application starts logging to it as the other user.

At work we have an archive of digital maps going back 15+ years. These old maps are saved in a variety of formats such as PostScript, EMF, PRN, hpgl2, pdf, etc. that most programs don't understand. Or you need a dozen different programs to see them all.

To facilitate easy searching and browsing of all these different formats we create jpeg versions of the maps, and then use touch to make the jpeg file match the original source file timestamp -- often years after the original was made.

Now we can use a single program such as Picasa to see the whole library and trivially locate certain date ranges. Without touch we'd have to add date metadata for every single image, probably manually, and then search on those strings when looking for a specific date range.

I have not used it for this purpose yet, but I have a script that reads the files and their dates from a directory and reads them for use on a web page. If I have to edit one, it will change its date. I have considered touching them to reset their order.

I have a cron job that gets the changes from a database that have occurred between the last run of the job, and the current run. It produces an XML file of the changes which are then processed into a different database. It gets the last run time from the time-stamp on the XML output file.*

If anything goes awry in the processing of the XML file I might want to repeat the run from the original date not from the date referred to on the time-stamp of the new XML file.

The simplest way to do this, rather than editing the scripts that are called etc. is to touch the XML file and force the time-stamp to be the date I require.

Also if I start afresh (with no previous XML output file) I can simply simulate its existence using touch.

[*] Before someone points it out - I realize the time the job starts and the writing of the XML file leaves a time gap of a few minutes where DB changes could occur. The job runs at a time when DB changes are extremely unlikely. That's my excuse and I'm sticking to it :-)