Why it doesn't work

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¹.

Why this typically 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.

Solutions

This all has to do with enabling PHP development in a single-developer scenario (ie: without SCM).

Ok, stop right there. Just because there's a single developer doesn't mean you shouldn't use SCM. You should be using SCM. Have the developer check in a file, and give him a way to press a “deploy” button to check out the files from SCM into the live directory.

There is absolutely no technical reason why you shouldn't be using SCM, but there may be a human reason. If the person working on these files styles himself “developer”, he should be using SCM. But if this is a non-technical person pushing documents in, SCM might be too complicated. So go on pushing the files over FTP or SSH. There are three ways this can work.

• Do you really need to synchronize times? As indicated above, rsync has an option to not synchronize times. Scp doesn't unless you tell it to. I don't know WinSCP but it probably can too.
• Continue doing what you're doing, just ignore messages about times. The files are still being copied. This isn't a good option, because ignoring errors is always risky. But it is technically possible.
• If you need flexibility in populating the files owned by the apache user, then the usual approach would be to allow the user SSH access as apache. The easy approach is to have the user create an SSH private key and add the corresponding public key to ~apache/.ssh/authorized_keys. This means the user will be able to run arbitrary commands as the apache user. Since you're ok with giving the user sudo rights anyway, it doesn't matter in your case. It's possible, but not so easy, to put more restrictions (you need a separate user database entry with a different name, the same user ID, a restricted shell and a chroot jail; details in a separate question, though this may already be covered on this site or on Server Fault).

¹ _{Or, for an empty file, write a byte and then truncate.}
² _{Barring additional complications, but none that I know of applies here.}

Why it doesn't work

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¹.

Why this typically 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.

Solutions

This all has to do with enabling PHP development in a single-developer scenario (ie: without SCM).

Ok, stop right there. Just because there's a single developer doesn't mean you shouldn't use SCM. You should be using SCM. Have the developer check in a file, and give him a way to press a “deploy” button to check out the files from SCM into the live directory.

There is absolutely no technical reason why you shouldn't be using SCM, but there may be a human reason. If the person working on these files styles himself “developer”, he should be using SCM. But if this is a non-technical person pushing documents in, SCM might be too complicated. So go on pushing the files over FTP or SSH. There are three ways this can work.

• Do you really need to synchronize times? As indicated above, rsync has an option to not synchronize times. Scp doesn't unless you tell it to. I don't know WinSCP but it probably can too.
• Continue doing what you're doing, just ignore messages about times. The files are still being copied. This isn't a good option, because ignoring errors is always risky. But it is technically possible.
• If you need flexibility in populating the files owned by the apache user, then the usual approach would be to allow the user SSH access as apache. The easy approach is to have the user create an SSH private key and add the corresponding public key to ~apache/.ssh/authorized_keys. This means the user will be able to run arbitrary commands as the apache user. Since you're ok with giving the user sudo rights anyway, it doesn't matter in your case. It's possible, but not so easy, to put more restrictions (you need a separate user database entry with a different name, the same user ID, a restricted shell and a chroot jail; details in a separate question, though this may already be covered on this site or on Server Fault).

¹ _{Or, for an empty file, write a byte and then truncate.}
² _{Barring additional complications, but none that I know of applies here.}

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.

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.

Why it doesn't work

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.

Why this typically 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.

Solutions

This all has to do with enabling PHP development in a single-developer scenario (ie: without SCM).

Ok, stop right there. Just because there's a single developer doesn't mean you shouldn't use SCM. You should be using SCM. Have the developer check in a file, and give him a way to press a “deploy” button to check out the files from SCM into the live directory.

There is absolutely no technical reason why you shouldn't be using SCM, but there may be a human reason. If the person working on these files styles himself “developer”, he should be using SCM. But if this is a non-technical person pushing documents in, SCM might be too complicated. So go on pushing the files over FTP or SSH. There are three ways this can work.

• Do you really need to synchronize times? As indicated above, rsync has an option to not synchronize times. Scp doesn't unless you tell it to. I don't know WinSCP but it probably can too.
• Continue doing what you're doing, just ignore messages about times. The files are still being copied. This isn't a good option, because ignoring errors is always risky. But it is technically possible.
• If you need flexibility in populating the files owned by the apache user, then the usual approach would be to allow the user SSH access as apache. The easy approach is to have the user create an SSH private key and add the corresponding public key to ~apache/.ssh/authorized_keys. This means the user will be able to run arbitrary commands as the apache user. Since you're ok with giving the user sudo rights anyway, it doesn't matter in your case. It's possible, but not so easy, to put more restrictions (you need a separate user database entry with a different name, the same user ID, a restricted shell and a chroot jail; details in a separate question, though this may already be covered on this site or on Server Fault).