Ext3 users - Jun 2009 - What is the difference between cat and vim command to file system?

Hi,

why use cat command to edit a file , the blocks of the file will not change.

but use vim command to edit a file, the blocks of the file will change?

Thanks in advance!

-- 
Regards,
Sucan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20090610/16f9ec5f/attachment.htm>

an example test case might be useful.
I'm not clear what you're trying to do, or what the problem is.

On Tue, Jun 9, 2009 at 10:40 PM, Sucan Zhang <bitzsk at gmail.com> wrote:
> Hi,
>
> why use cat command to edit a file , the blocks of the file will not
> change.
>
> but use vim command to edit a file, the blocks of the file will change?
>
> Thanks in advance!
>
> --
> Regards,
> Sucan
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users at redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>


-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/ext3-users/attachments/20090610/bd68134f/attachment.htm>

On Wed, Jun 10, 2009 at 01:40:20PM +0800, Sucan Zhang
wrote:
> 
> why use cat command to edit a file , the blocks of the file will not
change.
If you do "cat > file" or "echo foo > file", the file
is first getting
truncated, and so _normally_ the block of the file which will get
reallocated will be the same.   It doesn't have to be, however.

It also means that if you do:

cat > file
foo
foo
foo
^D

and you crash before the ^D, the file will be lost.
> but use vim command to edit a file, the blocks of the file will change?
An carefully written editor such as vim will tend to do something like this:

1) write the new contest to file.new
2) fsync file.new to make sure the blocks are safely on disk
3) rename file.new to file, which will delete file and replace it with file.new

That way if you crash in the middle of writing out the file, you don't
lose the contents of the file.


The bottom line is if you are really trying to do file-level security
controls using block numbers, you need to reestablish the block
numbers each time the filesystem has changed.  As I mentioned, this
also means you have to include the blocks for the inode table and the
blocks containing the directory.  It works only if the filesystem is
static --- and you want to prevent anyone from changing directories
and filenames.  In general, it's really not a great way of doing
partial security on filesystems.  You may be better off using SELinux
or Apparmor.

					- Ted