Lost file using Vim (first time ever in 15 years)

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Lost file using Vim (first time ever in 15 years)

Toddintr
For the first time ever since I started using Vim, I lost a file.  I had a modeline that specified an "encoding" setting for a Python script.  Vim complained when opening the file.  I googled for a solution, decided to try fileencoding instead of encoding.  When saving the file, I saw some error/warning messages, but went ahead with a ZZ or w! (don't quiet remember).  Result: File length of zero.  (Had backups disabled.)

My point: I *LOVE* Vim.  However, this sort of design decision is unacceptable.  It seems to be a design decision because it was not a bug or a crash.

My two-cents' worth.

Todd

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Toddintr
Version: Vim 7.3, 2010 Aug 15, Compiled Oct 27 2010, on Windows 7.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Alessandro Antonello
In reply to this post by Toddintr

First of all, not encoding nor fileencoding will work on modelines because the file was already loaded. See ':h encoding' and ':h fileencoding' for that.

In my opinion, there is no bad design. You disabled write backups. That is the way Vim keeps your original file safe.

Sorry for your lost.

Em 13/05/2012 05:10, "Toddintr" <[hidden email]> escreveu:
For the first time ever since I started using Vim, I lost a file.  I had a modeline that specified an "encoding" setting for a Python script.  Vim complained when opening the file.  I googled for a solution, decided to try fileencoding instead of encoding.  When saving the file, I saw some error/warning messages, but went ahead with a ZZ or w! (don't quiet remember).  Result: File length of zero.  (Had backups disabled.)

My point: I *LOVE* Vim.  However, this sort of design decision is unacceptable.  It seems to be a design decision because it was not a bug or a crash.

My two-cents' worth.

Todd

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Christian Brabandt
In reply to this post by Toddintr
Hi Toddintr!

On So, 13 Mai 2012, Toddintr wrote:

> For the first time ever since I started using Vim, I lost a file.  I had a modeline that specified an "encoding" setting for a Python script.  Vim complained when opening the file.  I googled for a solution, decided to try fileencoding instead of encoding.  When saving the file, I saw some error/warning messages, but went ahead with a ZZ or w! (don't quiet remember).  Result: File length of zero.  (Had backups disabled.)
>
> My point: I *LOVE* Vim.  However, this sort of design decision is unacceptable.  It seems to be a design decision because it was not a bug or a crash.
>
> My two-cents' worth.

Can you reproduce it?

regards,
Christian
--

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Toddintr
I have been able to reproduce it.  I have "vim_error.py" file with followoing contents:

# vim: set fileencoding=cp857:

ı

The file has three lines, the modeline, the second line, which is blank, and the third line, where there is a dotless lowercase i from the 857 code page.

File loads fine in Vim.  Then I change 'fileencoding' in the modeline to 'encoding' (i.e. just delete the four characters 'file' from 'fileencoding'), everything else remaining the same.

Result:

"vim_error.py" (in yellow)
"vim_error.py" E513: write error, conversion failed (make 'fenc' empty to override)
WARNING: Original file may be lost or damaged
don't quit the editor until the file is successfully written! (In orange)
Press ENTER or type command to continue (in green)

What I meant by bad design decision: When the conversion fails, why not simply restore the previous buffer?  The unacceptable behaviour is that even if I do a "q!", I still lose the file.

Thanks -

Todd

On Sunday, May 13, 2012 2:20:10 PM UTC+3, Christian Brabandt wrote:

> Hi Toddintr!
>
> On So, 13 Mai 2012, Toddintr wrote:
>
> > For the first time ever since I started using Vim, I lost a file.  I had a modeline that specified an "encoding" setting for a Python script.  Vim complained when opening the file.  I googled for a solution, decided to try fileencoding instead of encoding.  When saving the file, I saw some error/warning messages, but went ahead with a ZZ or w! (don't quiet remember).  Result: File length of zero.  (Had backups disabled.)
> >
> > My point: I *LOVE* Vim.  However, this sort of design decision is unacceptable.  It seems to be a design decision because it was not a bug or a crash.
> >
> > My two-cents' worth.
>
> Can you reproduce it?
>
> regards,
> Christian
> --

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

shawn wilson


On May 13, 2012 7:53 AM, "Toddintr" <[hidden email]> wrote:
>

> WARNING: Original file may be lost or damaged
> don't quit the editor until the file is successfully written! (In orange)
> Press ENTER or type command to continue (in green)
>
> What I meant by bad design decision: When the conversion fails, why not simply restore the previous buffer?  The unacceptable behaviour is that even if I do a "q!", I still lose the file.
>

So you get a warning about loosing data if you quit, quit anyway, and complain that you lost data? Interesting.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Christian Brabandt
In reply to this post by Toddintr
Hi Toddintr!

On So, 13 Mai 2012, Toddintr wrote:

> I have been able to reproduce it.  I have "vim_error.py" file with followoing contents:
>
> # vim: set fileencoding=cp857:
>
> ı
>
> The file has three lines, the modeline, the second line, which is blank, and the third line, where there is a dotless lowercase i from the 857 code page.
>
> File loads fine in Vim.  Then I change 'fileencoding' in the modeline to 'encoding' (i.e. just delete the four characters 'file' from 'fileencoding'), everything else remaining the same.
>
> Result:
>
> "vim_error.py" (in yellow)
> "vim_error.py" E513: write error, conversion failed (make 'fenc' empty to override)
> WARNING: Original file may be lost or damaged
> don't quit the editor until the file is successfully written! (In orange)
> Press ENTER or type command to continue (in green)
>
> What I meant by bad design decision: When the conversion fails, why not simply restore the previous buffer?  The unacceptable behaviour is that even if I do a "q!", I still lose the file.

You get a warning, that writing failed and the file may possibly be
corrupt. Vim even tells you, what you should do to write without
converting the content. What else should Vim do?

I don't understand, what Vim should possibly restore?

regards,
Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Toddintr
In reply to this post by shawn wilson
I never read the warning.  Much like no one reads the manual.  I never thought I would *ever* encounter anything with Vim that would lead to losing a file. 

> ... complain that you lost data?  Interesting.

Please spare me the attitude.  I am not complaining, but trying to provide feedback to help improve the product.

When you lose a file someday, you just might understand such detached, indifferent approaches to usability mean little to the end-user.


On Sun, May 13, 2012 at 3:09 PM, shawn wilson <[hidden email]> wrote:


On May 13, 2012 7:53 AM, "Toddintr" <[hidden email]> wrote:
>

> WARNING: Original file may be lost or damaged
> don't quit the editor until the file is successfully written! (In orange)
> Press ENTER or type command to continue (in green)
>
> What I meant by bad design decision: When the conversion fails, why not simply restore the previous buffer?  The unacceptable behaviour is that even if I do a "q!", I still lose the file.
>

So you get a warning about loosing data if you quit, quit anyway, and complain that you lost data? Interesting.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Toddintr
In reply to this post by Christian Brabandt
I am assuming that prior to attempting to write the file and failing, Vim had a valid copy in the buffer.  It should restore that copy.

Otherwise, if it is going to attempt something that is not reversible, it should never attempt it.  It is one of the fundamentals of software systems design as I know it.  Losing a file is the worst thing that an editor can do.

On Sunday, May 13, 2012 3:31:38 PM UTC+3, Christian Brabandt wrote:

> Hi Toddintr!
>
> On So, 13 Mai 2012, Toddintr wrote:
>
> > I have been able to reproduce it.  I have "vim_error.py" file with followoing contents:
> >
> > # vim: set fileencoding=cp857:
> >
> > ı
> >
> > The file has three lines, the modeline, the second line, which is blank, and the third line, where there is a dotless lowercase i from the 857 code page.
> >
> > File loads fine in Vim.  Then I change 'fileencoding' in the modeline to 'encoding' (i.e. just delete the four characters 'file' from 'fileencoding'), everything else remaining the same.
> >
> > Result:
> >
> > "vim_error.py" (in yellow)
> > "vim_error.py" E513: write error, conversion failed (make 'fenc' empty to override)
> > WARNING: Original file may be lost or damaged
> > don't quit the editor until the file is successfully written! (In orange)
> > Press ENTER or type command to continue (in green)
> >
> > What I meant by bad design decision: When the conversion fails, why not simply restore the previous buffer?  The unacceptable behaviour is that even if I do a "q!", I still lose the file.
>
> You get a warning, that writing failed and the file may possibly be
> corrupt. Vim even tells you, what you should do to write without
> converting the content. What else should Vim do?
>
> I don't understand, what Vim should possibly restore?
>
> regards,
> Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Toddintr
Also, I did not think that q! would result in any change to the file since the last write.  This is against user expectations.

On Sunday, May 13, 2012 3:58:44 PM UTC+3, Toddintr wrote:

> I am assuming that prior to attempting to write the file and failing, Vim had a valid copy in the buffer.  It should restore that copy.
>
> Otherwise, if it is going to attempt something that is not reversible, it should never attempt it.  It is one of the fundamentals of software systems design as I know it.  Losing a file is the worst thing that an editor can do.
>
> On Sunday, May 13, 2012 3:31:38 PM UTC+3, Christian Brabandt wrote:
> > Hi Toddintr!
> >
> > On So, 13 Mai 2012, Toddintr wrote:
> >
> > > I have been able to reproduce it.  I have "vim_error.py" file with followoing contents:
> > >
> > > # vim: set fileencoding=cp857:
> > >
> > > ı
> > >
> > > The file has three lines, the modeline, the second line, which is blank, and the third line, where there is a dotless lowercase i from the 857 code page.
> > >
> > > File loads fine in Vim.  Then I change 'fileencoding' in the modeline to 'encoding' (i.e. just delete the four characters 'file' from 'fileencoding'), everything else remaining the same.
> > >
> > > Result:
> > >
> > > "vim_error.py" (in yellow)
> > > "vim_error.py" E513: write error, conversion failed (make 'fenc' empty to override)
> > > WARNING: Original file may be lost or damaged
> > > don't quit the editor until the file is successfully written! (In orange)
> > > Press ENTER or type command to continue (in green)
> > >
> > > What I meant by bad design decision: When the conversion fails, why not simply restore the previous buffer?  The unacceptable behaviour is that even if I do a "q!", I still lose the file.
> >
> > You get a warning, that writing failed and the file may possibly be
> > corrupt. Vim even tells you, what you should do to write without
> > converting the content. What else should Vim do?
> >
> > I don't understand, what Vim should possibly restore?
> >
> > regards,
> > Christian

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

shawn wilson
In reply to this post by Toddintr


On May 13, 2012 8:53 AM, "A.M. Sabuncu" <[hidden email]> wrote:
>
> I never read the warning.  Much like no one reads the manual.  I never thought I would *ever* encounter anything with Vim that would lead to losing a file. 
>

Ok, I don't run windows so when I get a message I *read* it. If the message happens to repeat, I figure out how to disable it.

You've never encountered anything in VI that makes you loose a file? Huh, I do it all the time. Process: vim somefile, start typing, ah I don't like that filename, :q! and that data is gone. I don't even get a warning.
/me omits sarcastic thoughts

Also, you use VI without reading the manual? That's impressive.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

shawn wilson
In reply to this post by Toddintr


On May 13, 2012 9:00 AM, "Toddintr" <[hidden email]> wrote:
>
> Also, I did not think that q! would result in any change to the file since the last write.  This is against user expectations.
>

If this is true, this is quite odd...

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Christian Brabandt
In reply to this post by Toddintr
Hi Toddintr!

(Please don't top poste and please wrap to 75 columns)

On So, 13 Mai 2012, Toddintr wrote:

> I am assuming that prior to attempting to write the file and failing,
> Vim had a valid copy in the buffer.  It should restore that copy.
>
> Otherwise, if it is going to attempt something that is not reversible,
> it should never attempt it.  It is one of the fundamentals of software
> systems design as I know it.  Losing a file is the worst thing that an
> editor can do.

The copy is still in the buffer. It is valid. The problem is, that
writing failed because converting to your desired fileencoding failed.

The problem is probably, that Vim opened the file for writing, truncated
it and when writing noticed the error. But at this time, the old
contents are already gone.

Besides, big red warning messages should always be read, because they
don't usually happen.

regards,
Christian
--

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Toddintr
In reply to this post by shawn wilson
On Sunday, May 13, 2012 4:33:40 PM UTC+3, shawn wilson wrote:

> Process: vim somefile, start typing, ah I don't like that filename, :q! and
> that data is gone. I don't even get a warning.

I see.  I was not aware that you are a beginner, in grammar school.  

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Erik Christiansen
In reply to this post by Toddintr
On 13.05.12 15:52, A.M. Sabuncu wrote:
> I never read the warning.  Much like no one reads the manual.  I never
> thought I would *ever* encounter anything with Vim that would lead to
> losing a file.

Ah, but Vim is only _largely_ foolproof. It is not proof against
deliberate self harm. It might be worth reading enough to understand
that "q!" is "Forced Quit", and so you didn't "lose" a file, but
deliberately discarded it by choice. The "Forced Quit" is quite useful
when used, if not intelligently, then at least consciously.

However, a lesson learnt the hard way is usually a lesson well learned.

Happy reading!

Erik

--
"Unix was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Toddintr
In reply to this post by Christian Brabandt
Christian:

> The copy is still in the buffer. It is valid. The problem is, that
> writing failed because converting to your desired fileencoding failed.
>
> The problem is probably, that Vim opened the file for writing, truncated
> it and when writing noticed the error. But at this time, the old
> contents are already gone.

This explains the current way Vim handles the process.  It does not have to be this way.  This is what I mean by bad design.  Loss of data should only happen in an unforeseen situation (a crash, etc).  If you are truncating a file, especially prior to a conversion that can fail, you should take extra precautions.

> Besides, big red warning messages should always be read, because they
> don't usually happen.

This is the "Soviet" style of user interface design: it dictates *how* people should use a product, and ignores the real-life scenarios.  (Much like the opening line of your message - "Please don't top poste and please wrap to 75 columns.")  If I *really* care about customer feedback, I don't care how the customer sends me feedback / it can be top-posted, bottom-posted, sideways.  What is important is that I am getting feedback about the worst thing that can happen w/ my product.

I am done w/ this issue, thank you all for your responses.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Jan Larres
In reply to this post by Christian Brabandt
Christian Brabandt <[hidden email]>:
> The problem is probably, that Vim opened the file for writing,
> truncated it and when writing noticed the error. But at this time, the
> old contents are already gone.

But doesn't Vim first write the contents to a temporary file and then
rename it, at least in cases where the file isn't a symlink? In that
case the temporary file could be deleted instead of renamed if Vim
detects that the writing failed. It would be interesting to know the
value of 'backupcopy' here.

Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
If Jesus had been killed 20 years ago, Catholic school children would be
wearing little Electric Chairs around their necks instead of crosses.
                -- Lenny Bruce

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Toddintr
In reply to this post by Erik Christiansen
On Sunday, May 13, 2012 4:55:12 PM UTC+3, Erik Christiansen wrote:

> Ah, but Vim is only _largely_ foolproof. It is not proof against
> deliberate self harm. It might be worth reading enough to understand
> that "q!" is "Forced Quit", and so you didn't "lose" a file, but
> deliberately discarded it by choice. The "Forced Quit" is quite useful
> when used, if not intelligently, then at least consciously.
>
> However, a lesson learnt the hard way is usually a lesson well learned.

Typical engineer mentality, lack of any experience with real-life scenarios.

Furthermore, you are wrong.  The q! should take me to the prior state of the file, which was an intact buffer before the conversion attempt.  Prior to the q!, I did not do a 1,$d.

You are a good example of this entire community - looking down on others with snide remarks.  Good luck to you.  (Thank God there is stackoverflow where such bulls**t is not tolerated.)

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

meino.cramer
In reply to this post by Toddintr
Toddintr <[hidden email]> [12-05-13 16:00]:

> Christian:
>
> > The copy is still in the buffer. It is valid. The problem is, that
> > writing failed because converting to your desired fileencoding failed.
> >
> > The problem is probably, that Vim opened the file for writing, truncated
> > it and when writing noticed the error. But at this time, the old
> > contents are already gone.
>
> This explains the current way Vim handles the process.  It does not have to be this way.  This is what I mean by bad design.  Loss of data should only happen in an unforeseen situation (a crash, etc).  If you are truncating a file, especially prior to a conversion that can fail, you should take extra precautions.
>
> > Besides, big red warning messages should always be read, because they
> > don't usually happen.
>
> This is the "Soviet" style of user interface design: it dictates *how* people should use a product, and ignores the real-life scenarios.  (Much like the opening line of your message - "Please don't top poste and please wrap to 75 columns.")  If I *really* care about customer feedback, I don't care how the customer sends me feedback / it can be top-posted, bottom-posted, sideways.  What is important is that I am getting feedback about the worst thing that can happen w/ my product.
>
> I am done w/ this issue, thank you all for your responses.
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>

A software which warns users about potentially data loss and kills the
data, when the user ignores the warning is better than a software,
which only kills the data.
No doubt.
The better software dont kills the data first and tries then to
(re-)store it with a newer version of the data. The better software
keeps the old data, tries to write the new one, and - if it fails -
restores the old version. If it does not fail, it is safe to kill
the old version. Better to be safe than to be sorry ...

Think of makeing backups of a system: Would you delete the old backups
before preparing the new one?

Only my two cents,...,your software may vary...

--
mcc

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Lost file using Vim (first time ever in 15 years)

Sergey Khorev
In reply to this post by Toddintr
> If I *really* care about customer feedback, I don't care how the customer sends me
> feedback / it can be top-posted, bottom-posted, sideways.  What is important is that
> I am getting feedback about the worst thing that can happen w/ my product.

I doubt the Vim community owes you anything.
Anyway, Vim follows standard Unix way: provide reasonably safe
defaults but allow a users go and shoot himself in the leg if he wants
to. You disabled 'backup' and 'writebackup' without realising the
consequences, you got what you wanted.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
123