I am aware that the touch command is used to update the date of last modification on a file. It is also used to create a new file if requested file does not exist on file system.

Since touch (as it's name implies), should just update last mod date, why does it also try to create a new file?

Is it just a check written in the touch's code, or is it something else that causes a file to be created?

  • As a usage case, I use touch /forcefsck to create an empty file called /forcefsck to force file systems to be checked for errors on the next reboot. The file itself doesn't need to contain anything, it just needs to exist. Without touch, I'd need to use vi or nano to save a blank file. Much quicker to use touch.
    – Tim
    May 14, 2015 at 8:53
  • @Tim There's no real reason you couldn't use >/forcefsck or printf '' >>/forcefsck (the latter would preserve any existing contents). What you describe is a way to use a utility that works in a certain way, but that has no real bearing on why it's written to work that way.
    – user
    Jul 18, 2016 at 12:17
  • If this question is about the design of touch rather than how it works, I think touch violates the Single Responsibility Principle with the file creation side effect. Therefore, the "why" is simply due to early design choices that got stuck due to popularity and prevalence/ease of use. Jan 15, 2018 at 18:20

2 Answers 2


touch creates a new, empty file if the file doesn't exist because that's what it was designed to do. The utility has to contain code to handle that case specifically. The utility appeared in Unix V7; its manual described it thus:

touch — update date last modified of a file

touch attempts to set the modified date of each file. This is done by reading a character from the file and writing it back. If a **file* does not exist, an attempt will be made to create it unless the -c option is specified.

(I don't know what touch did if the file was empty. The underlying system call came later.)

I don't know for sure why touch was designed to make the file exist, but I suspect it's because of make. Why would you want to set a file's modification time to the current time? There are cases where it could be useful to set the modification time to a particular time, but that ability came later, the original touch could only set the modification time to the current time. A reason to do that is to re-run a make rule that depends on the file.

That is, suppose you have a file foo, and a makefile that declares a command to generate bar from foo. When you type make bar, the command is executed and bar is created. If bar exists and is newer than foo, make bar does nothing, because make assumes that bar has already been generated. However, if bar is older than foo, make thinks that bar is not up-to-date and needs to be regenerated.

But what if the rules to generate bar have changed? Then you have two options:

  • rm bar; make bar
  • touch foo; make bar

You would need foo to exist in order to generate bar, otherwise the command would typically not work.

The “touch” terminology was also present in the make utility: make -t bar would only pretend to run the commands, that is, it would set the modification time of bar to the current time without actually running the command to generate bar (you would do this if you thought that the changes to foo shouldn't affect bar). The touch utility was therefore a standalone version of the make -t feature.


Using strace touch t yields:


It is in touch's code and I wouldn't call it a check though. The timestamp is updated by opening the file for writing and then just closing it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .