Talk:Make a backup file: Difference between revisions

Content added Content deleted
(→‎Why no copying?: Less work)
Line 24: Line 24:


Backup involves copying, and must do since otherwise it is the same file and will be modified by the subsequent update. (Or alternatively it has to have some very special support from the OS; there's no POSIX operation for “checkpoint this file to this other name without copying” IIRC.) The whole strength of backups comes from copying. –[[User:Dkf|Donal Fellows]] 15:42, 11 November 2011 (UTC)
Backup involves copying, and must do since otherwise it is the same file and will be modified by the subsequent update. (Or alternatively it has to have some very special support from the OS; there's no POSIX operation for “checkpoint this file to this other name without copying” IIRC.) The whole strength of backups comes from copying. –[[User:Dkf|Donal Fellows]] 15:42, 11 November 2011 (UTC)
: This depends on the OS and on the pattern of accesses applications use on the file. Under unix, if anything has the file open for writing, then renaming it means they will update the backup. But if everything uses the "rename and write new copy" system, then it can be safe (though, of course, there's also the issue of more recent backups overwriting older backups). --[[User:Rdm|Rdm]] 15:48, 11 November 2011 (UTC)
: This depends on the OS and on the pattern of accesses applications use on the file. Under unix, if anything has the file open for writing, then renaming it means they will update the backup.
:: this is of course a concern, but only if multiple processes deal with a file which is not the concern of this task. also if a copy of a file is made while another process writes to it the the problems are not any less.--[[User:EMBee|eMBee]] 16:06, 11 November 2011 (UTC)
: But if everything uses the "rename and write new copy" system, then it can be safe (though, of course, there's also the issue of more recent backups overwriting older backups). --[[User:Rdm|Rdm]] 15:48, 11 November 2011 (UTC)
:It seems faster to just rename the file. With copying it goes like this: create the new file (.backup), copy the contents of the old file to the new file, clear the old file, write new data to the old file. Without it goes like this: rename the old file to a new name (.backup), create the old file again (already empty), write new data to the newly created file (with the old name). --[[User:Mwn3d|Mwn3d]] 15:52, 11 November 2011 (UTC)
:It seems faster to just rename the file. With copying it goes like this: create the new file (.backup), copy the contents of the old file to the new file, clear the old file, write new data to the old file. Without it goes like this: rename the old file to a new name (.backup), create the old file again (already empty), write new data to the newly created file (with the old name). --[[User:Mwn3d|Mwn3d]] 15:52, 11 November 2011 (UTC)
:good question. thanks for asking. copying is more expensive than rename. copying can fail (due to lack of space for example). if the machine dies before the copied file is written to the disk, which may be some time after the OS signaled that the copy is complete, and you already started to write the to the old file, then both may be lost. rename guarantees that the data is not touched, and thus can hardly be corrupted. and i don't think a rename could cause a file to be deleted if the machine crashes while a rename happens. it's either got the old name or the new one (or in very obscure situations maybe both). as far as i can tell, <code>rename()</code> is posix. at least the <code>rename(2)</code> manpage makes that claim. it is atomic too...--[[User:EMBee|eMBee]] 16:06, 11 November 2011 (UTC)