Russell Cattelan wrote:
> > The following script was used.
> >
> > #!/bin/sh
> > echo Test > file1
> > cp file1 file2
> > rm file1
> >
> > When the script completes I hit the big red switch and sure enough.
> > After recovery the file1 does not exist (that is ok) but file2 is
> > empty and does not have data but it does have a size of 5 bytes.
> >
> > So something is biting us. I would expect file2 to be non existant
> > (because it didn't get written yet or the correct file. This is in
> > between.
I'm glad Seth found an example with basic commands which shows Vim isn't
really doing something strange.
> Actually this is exactly what should happen.
> The remove transaction was commited to log before the rm returned
> (probably) upon running recovery at mount time the log was replayed and the
> delete recorded in all appropiate meta data.
>
>
> File2 was created and committed to disk thus creating an inode with 0 bytes,
> cp then came along and wrote 5 bytes to the file, which ofcourse is was
> allocated "delayed"
> by default BUT the size update (being not logged... see previous email)
> was written directly
> to the inode, now you have an inode with size but no extents.
> Normally the flush daemons eventually come along and convert all
> "delayed" allocations
> to real extents and write them to disk, but when you wack the power
> before this happens
> you end up with a file with no extents thus a "hole".
>
>
> This is not an inconsitency in the FS just an inconsitency in file data,
> which as we all know is not something that can be guarenteed without data
> logging.
Of course I wouldn't expect data to be restored when I switch off a system
while it's busy with something. But when I copy a file, wait a couple of
seconds and then switch off the system, there is no reason the file is
gone. That the FS causes reordering of disk actions is understandable,
but it should take care that the negative effects of this are minimized. It
should detect that the disk isn't doing anything and that there is a perfect
chance to start writing dirty data in the cache. A fixed timeout of 30
seconds or even 1 second sounds like a lazy programmer that didn't want to
implement a satisfactory solution.
Summary: I consider this to be a problem with the filesystem, not with Vim.
For people that want to be sure their file is synced, the ":!sync" command can
be used.
--
I'm sure that I asked CBuilder to do a "full" install. Looks like I got
a "fool" install, instead. Charles E Campbell, Jr, PhD
/// Bram Moolenaar -- Bram@xxxxxxxxxxxxx -- http://www.moolenaar.net \\\
((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
\\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
|