#Ruby find word in file full#
#Ruby find word in file code#

Tempfile.fdatasync unless RUBY_PLATFORM =~ /mswin|mingw|windows/ Tempfile.puts line.gsub(regexp, replacement) Tempprefix.prepend('.') unless RUBY_PLATFORM =~ /mswin|mingw|windows/

#Ruby find word in file code#

Here's some code that implements the full-algorithm (windows code is untested and unfinished): #!/usr/bin/env rubyĭef file_edit(filename, regexp, replacement) However, if you have insufficient space to hold both copies then you are probably short on disk space and the actual risk of writing a truncated file is much higher, so I would argue this is a very poor tradeoff outside of some exceedingly narrow (and well-monitored) edge cases.

You must have enough space on the destination partition in order to hold both the complete old file and the new file.

For that reason you might want to fall back and try /tmp if opening the file in the destination directory fails.

Sometimes you may not be able to open a Tempfile there, such as if you are trying to 'edit' a file in /proc for example.

The only downsides to the approach of creating the Tempfile in the destination directory are: Any failures, such as device out of space, permission errors, etc., should be encountered during writing the Tempfile out. The mv itself should never fail, and you should always get a complete and untruncated file. This ensures that there will be no cross-device move issues.

What is more preferable is to open a Tempfile in the same directory as the old file. The system mv and cp commands behave similarly. This also has nothing to do with Ruby's implementation. This also defeats the purpose of using the filesystem mv commands and you may run the destination filesystem out of space with only a partially written file. This is most likely not what you want, and you may run into 'text file busy' errors if you try to edit the contents of a running file. The old file will be opened, the old files inode will be preserved and reopened and the file contents will be copied.

Probably more importantly, when you try to mv the file across a device mount you will transparently get converted to cp behavior. If /tmp is mounted on a different file system you may run /tmp out of space before you've written out the file that would otherwise be deployable to the destination of the old file. If you open a file in /tmp then you have to consider a few problems: You need to always use FileUtils.mv to move a fully-written temporary file into place.Ī final consideration is the placement of the temporary file.

#Ruby find word in file full#

The suggestion above to simply slurp the file into memory, manipulate it and write it out to the file will be guaranteed to produce zero-length files on a full filesystem. In languages where calling close() does not throw an exception (Perl or C) you must explicitly check the return of close() and throw an exception if it fails. Regardless of language, this is best practice. If you are very paranoid you should call the fdatasync() system call as a step 3.5 before moving the file into place. The ext4 filesystem has also been patched to support this kind of behavior. With ext3 filesystems you are guaranteed that the metadata write to move the file into place will not get rearranged by the filesystem and written before the data buffers for the new file are written, so this should either succeed or fail. Renames the new file and drops it into place.

(Catch this and cleanup the temporary file if you like, but you need to rethrow something or fail fairly hard at this point.įixes the file permissions and modes on the new file. (You need to be careful about slurping entire files into memory).Įxplicitly closes the new temporary file, which is where you may throw an exception because the file buffers cannot be written to disk because there is no space. Reads the old file and writes out to the new file. At a bare minimum write to a tempfile and move/rename the file into place like the 'simple' solution at the end of this answer. For that reason, I think the accepted answer should most likely not be the accepted answer. This is the kind of dataloss scenario which developers MUST consider because it will happen. If the process is aborted for any reason (ctrl-c, OOM killer, system crash, power outage, etc) during the write then the truncated file will also be left over, which can be catastrophic. There will always be a race condition where concurrent readers will see a truncated file. Note that in-place file editing like in the accepted answer will always truncate the file and write out the new file sequentially. This is catastrophic if you're doing something like writing out /etc/passwd files as part of system configuration management. Keep in mind that, when you do this, the filesystem could be out of space and you may create a zero-length file.