Let's say I write my code and then my computer dies, how much is necessary to do a full scan, if I don't want my later source code to get infected?
Let's say I am writing a Ruby on Rails program and while editing a file, the blue escaping of the machine. in this case, how much is it necessary to recheck the entire hard drive if I don't want my future files to get corrupted?
Let's say if the OS deletes the tmp file the moment my computer crashed and there are still some pointers to some sector on the hard drive. and if my newly created files are in this sector, and next time the OS clears the files again, it might seem that the left sector was not cleared the last time and cleared it again and corrupted our source code, (esp with Ruby on Rails where the source code can be generated by rails and not by us, and we cannot know why our rails server is down if the file is affected). we can rely on SVN, but what if the file is affected before we check it?
I think the official answer would be: "always scan the drive after a power failure or power outage, for data and even space and indicate trying to fix any bad sector", but the point is, with a hard drive this big nowadays, it might need to 2 hours to scan everything. And especially at work, we can't wait 2 hours if it's the middle of the day.
Does anyone know if there is a modern OS like XP, Vista, Mac OS and Linux (when sometimes the power cord was loose and it wouldn't close normally and just shut down at 0% battery) with these modern OSs, our original is the code safe? Do they know how to structure to write to a sector so that it is at best a waste sector instead of overlapping sectors?
a source to share
With modern journaling file systems (ext3 / 4, NTFS), the only problem is that the file may be in a "semi-written" state. Obviously scanning won't help this (which is what backups are for). The file system itself cannot be damaged. If you are using something like FAT, then yes, you should be concerned about that.
a source to share
There is really only 1 problem here.
Whether any file is currently being written in some "half-written" state.
The main reason for this is that the application / editor is writing the file and the machine dies halfway through. In this case, the file will be written, well, by half. If the original file was written, the original file is "gone" and the new one is "halfway". If you don't have a backup file, then you have a problem.
As for a file with dangling pointers or links to unwritten sectors or something similar. This problem depends on your filesystem.
Basic, modern ystems files are journaled and will "prevent" this from happening. You may have "half written", but that's because the application only got to write half of it, not the filesystem losing track of the sector pointer.
If you are playing with filesystems for performance, or something else (for example, using UFS without journaling), you need to run fschk to clean up the filesystem metadata.
But if you are using a modern operating system and filesystem (i.e. anything from the past 5 years), you won't have this problem.
Finally, if you have version control running, just execute "svn status", it will show you any "corrupted" files as they will be changed, and it will detect this as well.
a source to share
I see some information about
http://en.wikipedia.org/wiki/Journaling_file_system
Journaled file systems
File systems can provide journaling to provide safe recovery in the event of a system failure. A journaled file system writes some information twice: first to the journal, which is a log of file system operations, and then to the desired location on the regular file system. Journaling is handled by the file system driver and monitors every operation that changes the contents of the disk. In the event of a failure, the system can recover to a state by replaying a portion of the log. Many UNIX file systems provide journaling, including ReiserFS, JFS, and Ext3.
In contrast, non-journaled filesystems should generally be fully examined with a utility such as fsck or chkdsk for any inconsistencies after an unclean shutdown. Soft updates are an alternative to journaling that avoids redundant writes by carefully sequencing update operations. Log-structured filesystems and ZFS also differ from traditional journaled filesystems in that they avoid inconsistencies by always writing new copies of the data, avoiding in-place updates.
a source to share