|
|
|
This thread is locked; no one can reply to it.
|
| Backup files. |
|
Andrei Ellman
Member #3,434
April 2003
|
I am currently implementing backup-file functionality in my level-editor, and am wondering on the best way to implment it. The most obvious solution is to rename the file to the backup filename and then write out the saved level as normal, like so...
Unfortunately, this has the problem of losing any meta-data associated with the file (such as creation-date, file-owner, and I believe that on BeOS, meta-data can become quite involved). The alternative solution I had would be to copy the file byte by byte. But this has the disadvantage of being slow and inefficient (like when saving on a floppy disk), as it involves one read and two writes instead of one write. Also, the backup-file will not contain the meta-data of the original file. Are there any other recommended ways of creating backup files, or any libc functions I could use? Perhaps I could read in the meta-data of the backup file and apply it to the saved file (although this would probably vary from OS to OS, and I'm not sure if I can create a file belonging to a different owner). AE. -- |
|
Myrdos
Member #1,772
December 2001
|
Quote: The most obvious solution is to rename the file to the backup filename and then write out the saved level as normal That's what I would do. The meta-data will take care of itself - how can your 'normal' saves have the correct meta-data, but your 'backup' saves don't? The creation time will be whenever the backup occurred, which is what you'd want. The owner and everything else should be the same as a normal save. __________________________________________________ |
|
spunit262
Member #5,545
February 2005
 |
What you do is |
|
Andrei Ellman
Member #3,434
April 2003
|
David McCallum said:
Quote: The most obvious solution is to rename the file to the backup filename and then write out the saved level as normal That's what I would do. The meta-data will take care of itself - how can your 'normal' saves have the correct meta-data, but your 'backup' saves don't? Ummm... if the file is being renamed, then the renamed file will preserve the meta-data, but the newly saved file won't. The Backup file will have the creation date of the original file and the modification date of the original file's previous save, whereas the actual file being saved will have a creation and modification date equal to the current time. spunit262 said:
What you do is It's not just the creation date I want to change, it's the entire meta-data (including the file-owner) in an OS-independent way. spunit262 said:
Edit: Both these methods rely on .NET . I'm writing my program in plain C - no C++ or .NET . Is there a method in libc or any publically available C library that can create backup files? AE. -- |
|
spunit262
Member #5,545
February 2005
|
I figured that. |
|
Andrei Ellman
Member #3,434
April 2003
|
I've now written my backup code so that instead of renaming my file to the backup name and writing a new file, it instead makes a copy of the original file and then overwrites the original file with the backup file. This has the advantage that the meta-data is preserved (but not in the backup file), but the main dis-advantage is that it performs an un-necessary read and write of the file, which can be slow if using a slow medium such as a microfloppy. Anyway, here is the code I'm using now...
What would be nice is a libc function that would make a clone of a file under a different name, or even better, to create a new file with all the meta-data of an existing file (especially the original creation date). If anyone knows of a better method than either the one above or the one in my first post of implementing backup file functionality in C, or if there's a freely available platform-independent C library that can do this, then please let me know. Also, I've heard that on windows, fflush writes to the operating system buffer rather than the disk buffer unless either the program is linked with COMMODE.OBJ or the file-open mode-string includes the 'c' flag. Both these methods are windows only, and am wondering of there's an OS independent way to make sure that the disk-cache is fully flushed to disk. AE. -- |
|
Kitty Cat
Member #2,815
October 2002
 |
fflush is fully standard. It writes to the OS buffer because the program interacts with the OS, then the OS writes to the disk's DMA/IO port which then gets written to the disk. Unless you have a critical need to ensure the data is physically put on the disk before you continue (you usually don't), that's Good Enough (tm). The OS won't do things out of order. But anyway, here's my copy-file routine, which preserves as much as possible:
Could use a bit more error checking in the loop, but it's generally good enough unless you run out of disk-space. buffer is simply a static array. -- |
|
Andrei Ellman
Member #3,434
April 2003
|
Kitty Cat said: Unless you have a critical need to ensure the data is physically put on the disk before you continue (you usually don't), that's Good Enough (tm). The OS won't do things out of order. Is that also true if I'm writing a file and a backup-file and the order of the file-clusteres of the two files is heavily fragmented on the disk (the order of the parts of the two files is mixed up), then both files will be written in order. Because otherwise, if there's a power-failiure when the hard-drive is busy writing the data, then there's the possibility that both files could become corrupted. Also, in your copy-routine, I notice that you've used open() and fdopen() for the destination file. What advantage does this have over fopen()? AE. -- |
|
Kitty Cat
Member #2,815
October 2002
|
Quote: if there's a power-failiure when the hard-drive is busy writing the data, then there's the possibility that both files could become corrupted. If there's a power failure while writing, you're pretty much fucked regardless. The most you can do is use a proper journaling file system (NTFS, ext3, reiserfs, etc) so that the system can potentially recover the corrupted files, though there's still no gaurantee. That's all something the OS should worry about, not you. Quote: Also, in your copy-routine, I notice that you've used open() and fdopen() for the destination file. What advantage does this have over fopen()? Using open() I can specify the file mode, which I get from the source file (viastat()). That's so it preserves the proper permissions and such from the original file. -- |
|
Andrei Ellman
Member #3,434
April 2003
|
Thanks for that. However, it still does not preserve the creation date in the destination file (only tried it with a FAT32 filesystem so did not test for the ownership). Also, I'm sure there's a solution out there that preserves meta-data in the original file that just involves a rename instead of a copy. AE. -- |
|
Kitty Cat
Member #2,815
October 2002
|
Could always try rename, but I don't know if that preserves the original meta data. -- |
|
Andrei Ellman
Member #3,434
April 2003
|
rename does save me from having to read in and write out the original file, and it preserves the original meta-data in the backup file. However, once the new file is written, it will no longer have an original file to overwrite, and then, the meta-data in the original file will no longer be preserved. Surely there must be some form of metadata-preserving backup solution in C (using libc or some other freely available C library) that not only preserves the metadata in the original file, but also works without having to copy (read in and write out) the entire file. AE. -- |
|
Thomas Fjellstrom
Member #476
June 2000
 |
-- |
|
Andrei Ellman
Member #3,434
April 2003
|
Thomas Fjellstrom said: That looks like a UNIX-centric description of file-attributes. It appears that UNIX does not have the concept of a creation-time. After a bit of googling, I discovered what I think is the solution I've been searching for, but it's Windows-only - ReplaceFile(). Other Windows-only functions that might be of use are SetFileTime and CreateFile. Now if only there was a cross-platform way to do this. AE. -- |
|
|
