My System was crashed yesterday, the problem is that syntax is disable and set autoindent is not in use.
Even I remove this file, touch this file again, it remains not right!
Swap files are not meant to edit directly.
Swap files are special files that store pieces of Vim's state, and pieces of the unsaved file, in a Vim-specific format. These are not backup files.
You may be able to use the swap file to recover any edits-in-progress. To do that, simply edit the file you were editing when your system crashed. Vim will detect the swap file and prompt you to recover the file if it is able to do so.
That is, if you haven't invalidated the swap file format attempting to edit it in a misguided attempt to recover your file from it by hand.
Now, Vim does have a separate ability to make real backup files that are copies of your file, whenever it saves. But that doesn't help you from a system crash, that helps you when you mess up your file yourself while you edit, and then save it.
There is also a proposed new feature (in the todo list) for adding a command to recover an entire file from an undo file, if the file itself got deleted somehow, but that's not included in any released Vim yet.
Related
Hi I am trying to update one of my remote repositories. When I use commit in git bash it shows that a SWP file already exists and askes me if I want to (R)ead only the file (E)dit (D)elete. I tried editing the file, but I cannot save the changes and therefore cannot commit my changes. Any idea what is going on.
EDIT:
It's working now thanks to those that helped. In terms of the question I will try to only show the relevant information when asking questions in the future.
When you edit a file, Vim stores your changes in a "swap file" so that you can recover your work if Vim's process is killed before you could save. This can be caused by something as problematic as a system crash or, simply, by closing your terminal window while Vim is running.
If Vim is quitted "normally", it deletes the swap file it created.
If it is not, the swap file is left behind and, the next time you open the same file, Vim will notice the presence of the swap file and offer you the possibility to recover the work that you "lost" the last time Vim quitted "abnormally".
That is the interactive screen you get with the "(R)ead only the file (E)dit (D)elete" prompt.
Now, when you are starting out with stuff like Git, Vim, the command line, etc. it may happen quite often that you find yourself in an uncomfortable situation, not knowing exactly what to do to fix it. This is frankly quite normal at this stage. In those situations, closing the terminal window might seem like a good first step in going back to a more comfortable situation to start again. In some cases, however, doing so might leave a trail of hidden files and broken states that might make it harder than you hoped to get to that comfortable situation.
When you do $ git commit, Git populates a specific temporary file located in your local .git directory:
.git/COMMIT_EDITMSG
with some text describing the commit you are about to make, and opens that file with your designated editor, which is the dreaded Vim by default.
When you start editing the file, Vim creates a swap file. If you insert your commit message, write the file, and quit Vim normally, the swap file is deleted and you won't ever be prompted about it. If you close the terminal window before writing the file, the swap file stays behind and Vim will prompt you about it the next time you try to make a commit.
From there you have quite a few options…
Go into your .git directory and delete the swap file(s) manually. They should be named .git/.COMMIT_EDITMSG.swp (or .swo, .swn, etc. see :help swap-files in Vim). This should give you a clean state for the next time you do $ git commit.
Don't close your terminal window when faced with a problem. Instead, try to analyze what went wrong and look for proper ways to fix it. If you have to close the terminal window, look for stray swap files just in case.
Learn Vim's basics so that you don't have to close the terminal window when you mess up your commits. Try $ vimtutor.
Tell Git to use a text editor you are more familiar with. Search Stack Overflow, I am sure there are dozens of Q/As about that.
Configure Vim to never create swap files. You can do it in Vim's configuration file:
# in $HOME/.vimrc
set noswapfile
This won't tell it to ignore existing swap files, though, so you might want to delete them manually anyway.
Use a graphical Git client instead of the CLI.
I noticed that for whatever reason, my _vimrc wasn't being loaded this morning. I keep my entire vim directory saved to my Google Drive to the location I specify in my _vimrc. I didn't worry about it since I'd recently backed it up, but now when I dump it into my vim folder, whenever I start up gVim, it looks like it renames it to _vimrc.2014.
I can't find anything about this behavior, is it normal? It doesn't really affect me too much since it still gets source, but I just want to know why it's doing that.
Vim certainly is not doing this. I'm not certain it's causing YOUR problem, but Google Drive has problems replacing files with a new file of the same name. Under the hood, that is exactly what Vim is doing when it writes a file with default settings. See https://groups.google.com/d/topic/vim_use/jkw_nnHz9cE/discussion : you can use either the 'backupskip' or 'writebackup' options to force Vim to write the file directly instead of replacing it with a new file when editing inside your Google Drive folder. I'm using this line in my .vimrc to accomplish the task:
let &backupskip.=','.expand('$HOME/Google\ Drive/').'*'
I thought about a concurrency issue (in Solaris), what happen if while reading someone tries to delete the same file. I have a query regarding file existence in the Solaris/Linux. suppose I have a file test.txt, I have open it in vi editor, and then I have open a duplicate session and remove that file, but even after deleting that file I am able to read that file. so here are my questions:
Do I need to thinks about any locking mechanism while reading, so no one able to delete same file while reading.
What is the reason of showing different behavior from windows(like in windows if file is open in in some editor than we can not delete that file)
After removing that file, how I am still able to read that file, if I haven't closed file from vi editor.
I am asking files in general,but yes platform specific i.e. unix. what will happen if I am using a java program (buffer reader) for read file and file is deleted while reading, does buffer reader still able to read the file for next chunk or not?
You have basically 2 or 3 unrelated questions there. Text editors like to read the whole file into memory at the start of the editing session. Imagine every character you type being saved to disk immediately, with all characters after it in the file being rewritten one place further along to make room. That would be awful. Much better that the thing you're actually editing is a memory representation of the file (array of pointers to lines, probably with some metadata attached) which only gets converted back into a linear stream when you explicitly save.
Any relatively recent version of vim will notify you if the file you are editing is deleted from its original location with the message
E211: File "filename" no longer available
This warning is not just for unix. gvim on Windows will give it to you if you delete the file being edited. It serves as a reminder that you need to save the version you're working on before you exit, if you don't want the file to be gone.
(Note: the warning doesn't appear instantly - vim only checks for the original file's existence when you bring it back into the foreground after having switched away from it.)
So that's question 1, the behavior of text editors - there's no reason for them to keep the file open for the whole session because they aren't actually using it except at startup and during a save operation.
Question 2, why do some Windows editors keep the file open and locked - I don't know, Windows people are nuts.
Question 3, the one that's actually about unix, why do open files stay accessible after they're deleted - this is the most interesting one. The answer, guaranteed to shock you when presented directly:
There is no command, function, syscall, or any other method which actually requests deletion of a file.
Underlying rm and any other command that may appear to delete a file there is the system call unlink. And it's called unlink, not remove or deletefile or anything similar, because it doesn't remove a file. It removes a link (a.k.a. directory entry) which is an association between a file and a name in a directory. (Note: ANSI C added remove as a more generic function to appease non-unix people who had no intention of implementing unix filesystem semantics, but on unix, remove is just a rmdir if the target is a directory, and unlink for everything else.)
A file can have multiple links (see the ln command for how they are created), which means that the same file is known by multiple names. If you rm one of them, the others stick around and the file is not deleted. What happens when you remove the last link? Well, now you have a file with no name. But names are only one kind of reference to a file. There are at least 2 others: file descriptors and mmap regions. When the last reference to a file goes away, that's when the file is deleted.
Since references come in several forms, there are many kinds of events that can cause a file to be deleted. Here are some examples:
unlink (rm, etc.)
close file descriptor
dup2 (can implicitly closes a file descriptor before replacing it with a copy of a different file descriptor)
exec (can cause file descriptors to be closed via close-on-exec flag)
munmap (unmap memory region)
mmap (if you create a new memory map at an address that's already mapped, the old mapping is unmapped)
process death (which closes all file descriptors and unmaps all memory mappings of the process)
normal exit
fatal signal generated by the kernel (^C, segfault)
fatal signal sent from another process (kill)
I won't call that a complete list. And I don't encourage anyone to try to build a complete list. Just know that rm is "remove name", not "remove file", and files go away as soon as they're not in use.
If you want to destroy the contents of a file immediately, truncate it. All processes already using it will find that its size has suddenly become 0. (This is destruction as far as the normal file access methods are concerned. To destroy it more thoroughly so that even someone with raw disk access can't read what used to be there, you need to overwrite it. There's a tool called shred for that.)
I think your question has nothing to do with the difference between Windows/Linux. It's about how VI works.
when using VI to edit a file. VI will create a .swp file. And the .swp file is what you are actually editing. At the same time, if other users delete the original file will not effect your editing.
And when you type :w in VI, VI will use .swp file to overwrite the original file.
My log files are generated inside a particular directory on my Linux server. Sometimes when I view the log files inside that directory using ls -lart, I see:
abc.log
.abc.log.swp
Could anybody please explain why the log file has the name .abc.log.swp?
Those are vim "swap" files -- temporary files created by vim while you are editing a file. They are (usually) removed automatically when you exit the editor.
When you edit a file using vi and some other editors, the editor creates a temporary swap file with the .swp extension. If something goes wrong and the editor crashes or the computer dies, the swap file contains your changes so you can revert back to the edited file.
As soon as you close the editor, the swap file should be deleted. If it isn't, and you didn't experience a crash, you can simply remove the swap file.
Is it possible to automatically remove the swapfile when the file is saved, and automatically create it again when the file is changed?
And is this a good idea?
EDIT:
The reason for wanting to to this is so that I don't have to go through the diff process for files that had no changes after last save if the computer suddenly ran out of power or crashed.
The diff process referred to is; first open the file read only, saving it under a different filename, vimdiffing it and in the end delete it.
It doesn't happen often, but is just as annoying when it does.
Is it possible to automatically remove the swapfile when the file is saved, and automatically create it again when the file is changed?
And is this a good idea?
Deletion and creation of a file are relatively slow operations. It makes sense to keep the swap file in case if one going to keep editing. Or why else one would keep the VIM running?
Additionally VIM uses the swap file to detect attempts to edit the same file from different VIM instances.
All in all, I think it is a bad idea to try to remove the file.
P.S. Worth noting that when VIM is started in read-only mode as view or vim -R, it doesn't create the swap file. But if once you change the file, the swap file is going to be created.
I am assuming you have a long running vim session like I do (my first window in my screen session is always vim and it usually lives for several days, almost for the entire duration of the uptime). I think the swapfile is not kept around, if you simply close the buffer, unless you have the 'hidden' setting. What happens is that when you have the 'hidden' turned on for buffers, vim tries to keep all the undo history of the buffer, and so has to have the swapfile accessible, in case you come back to the buffer and start undoing changes. As for me, I don't like this feature and keep it turned off (which is the default) and so only have to deal with the swapfiles for those buffers that I actively have loaded in a vim window at the time of crash. Since I have macros that autosave my session every 5min., and since I also disable the Vim's default swapfile detected prompt, restarting my session after a crash is fairly painless.