RE: Odd file rename

You could, for the last part of lhowards answer use

rename OLDNAME, NEWNAME
[download]

instead of the link/unlink block - Although his answer is more robust if your OS supports it.
Update:I think Corion is correct, its been a long day.... I was thinking vaguely of the possibility of a race condition when using rename if another process is attempting to read the file. Is this possible? and if it is would flock sort things out. Also error handling would/could be better with the link/unlink method.

Comment on RE: Odd file rename Download Code

Replies are listed 'Best First'.
RE: RE: Odd file rename by Corion (Patriarch) on Jun 14, 2000 at 16:54 UTC
To be honest, I don't see where `rename()` would be less robust than the `link() / unlink()` combo. Both cases work only on the same file system, both cases do otherwise the Right Thing, except that `rename()` is atomic, where `link / unlink` are two different statements. In the case of failure, both statements leave the original file untouched, but if the `unlink()` fails, you are left with an additional link to the old file, which is not always what you want ... Update : And even Larry Wall claims that `rename` is cool : `Besides, REAL computers have a rename() system call. :-)` [download]	[reply] [d/l]
RE: RE: RE: Odd file rename by lhoward (Vicar) on Jun 14, 2000 at 17:07 UTC
I proposed the link/unlink solution because IMHO it allows for finer granularity of error handling (not that my example took advantage of this, but I could have). Also, according to this earlier perlmonks article rename a user was experiencing rename failures which ended up deleting the file being renamed. Of course, this shouldn't be an issue if the perl rename function really just calls the system rename call. I guess this depends on which OS you are running.	[reply]


Problems? Is your data what you think it is?
	PerlMonks