Unfortunately, you don't describe your use case very precisely, so I can't recommend a solution (except maybe rsync --omit-dir-times, see below). I'm just going to explain why what you're doing doesn't work and the reason why this is usually not a problem.
WHen you attempt to change the modification time of a file with touch, or more generally with the underlying system call utime, there are two cases.
- You are attempting to set the file's modification time to a specific time. This requires that you are the owner of the file. (Technically speaking, the process's effective user ID must be the owner of the file.²)
- You are attempting to set the file's modification time to the current time. This works if and only if you have permission to write to the file. The reason for this exception is that you could achieve the same effect anyway by overwriting an existing byte of the file with the same value¹.
So what you're trying to do is supposed not to work. In practice, this often doesn't matter:
- When you copy files with ftp, scp, rsync, etc., the copy creates a new file that's owned by whoever did the copy. So the copier has the permission to set the file's times.
- With rsync, you won't be able to set the time of existing directories: they'll be set to the time when a file was last synchronized in them. In most cases, this doesn't matter. You can tell rsync not to bother with directory times by passing
--omit-dir-times(-O). - With version control systems, revision dates are stored inside files; the metadata on the files is mostly irrelevant.
¹ Or, for an empty file, write a byte and then truncate.
² Barring additional complications, but none that I know of applies here.