To expand on what RudiC (correctly) explained:

When a process (your syslog for example) writes to a file it has to open it first. To "open it" means issuing a system call fopen(). The OS gives back a "file handle" by which the process now can access the file (until it closes it, which means issuing another system call).

This file handle now identifies the file not by its name but by a more "personal" identification: the inode number. When you delete the file and create a new one with the same name in its place then exactly this has happened: a new file with the same name is in the place of the old file, but the new file and the old file are still distinct files and they have different inode numbers.

Think of it like this: some "John Smith" lives in an appartment. When he moves out and another guy, incidentally also named "John Smith", moves in, they are still not the same person, yes?

Therefore, until told otherwise, your process still writes into the old file, even if it is no longer visible because you deleted it. It even takes space on your harddisk until your process holds it open. Only when you stop the last process holding it open (more than one process could open a file simultaneously) it will be finally "unlinked" - the space it takes will be relinquished and its data be destroyed.

With sending a signal to the process you tell it to "start over": re-read its configuration files, open the necessary files anew, etc., similar to stopping and restarting it, but without the actual program stop and program start.

I hope this helps.

bakunin