I am using VSCode to remotely connect to a file server via SSH. I have another person who uses it as well and they are logging in under their own account, which is a part of a group that has access to an entire directory structure.
Every once in a blue moon, the permissions get screwed and revert back to root:root (ownership) and I have to change it back to root:groupname so that the other person can have access. However, even when I do this, sometimes the other person isn't able to make changes using VS Code. If I su to that user, I am able to save changes.
One thing that I have noticed is that if I run vim <filename> and try to edit it as that user, it'll say, "-- INSERT -- W10: Warning: Changing a readonly file". However, the minute I try to save the file, it actually saves.
It's almost like the permissions are lagging or something and hasn't been updated.
Any idea how I can go about fixing this?
There is code inside vim that does a pretty good job of deciding when a file has been opened by someone else with another editor for writing, and it stops you from a race condition for file write.
Vim is telling you to wait very patiently for the other person to be done writing that file.
Learn more with :help W10
Reproduce this bug in vim 9.0:
Make a /tmp/file.txt owned by youruser with rw-r--r--
Open two unique terminals to /tmp/
Open file.txt for writing in one using vim.
Vim will mark the file as read only awaiting write, since someone else has it open for writing.
Open file.txt for writing in one using vim in the other terminal.
You get:
"-- INSERT -- W10: Warning: Changing a readonly file"
Solutions:
Find the other instance of vim that has locked your file for writing and close that instance of vim. Done
Or if you don't have access to the other terminal, or the instance of the other editor died without releasing its read only lock, or if it's from another person who's opened the file for writing on a session from a different computer, then the only thing I know that can clear all of those conditions is rebooting the computer.
If you want more control over this, you'll have to uncover how vim is deciding when a file is readonly for writing and find out where this information is being stored and clear it manually.
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.
For the sake of security, I'm going to try to use non-administrator account only as far as possible. But It seems there's a time when I have to access root such as checking /var/log/secure that normal accounts can't reach.
I came across an interesting post. It says I can save a file I edited in vim without the needed permissions, rather than opening vim as root by using :w !sudo tee % > /dev/null. But, I think that's not the solution I had in mind because it only works under certain circumstances; there are many files in /var/log/ that a normal user don't have permission to read.
I was thinking: what if I make a script that opens vim the current user's vim configuration including a bunch of plugins automatically while using sudo.
But, I don't know how to do, and I'm not sure if this would cause a lot of security risks and even I'm doing right.
Thanks in advance.
Too late, what you want to create exists already:
$ sudo -e filename
This makes a temporary copy of filename, edits it with $EDITOR as the current user, replaces the original file with the new one on write, and deletes the temporary file.
About 10% of the time, when I attempt to save my file in Emacs I get the following error:
Opening output file: resource temporarily unavailable,
I'm currently using Emacs GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) on
Ubuntu 12.04. I've also verified that this issue occurs logged in as a different user and using Emacs 23.3.1.
This issue gets to be a real pain when I make a fix, attempt to save, and then wonder why my fix didn't happen.... only to find out later that the Emacs save was never successful.
If I notice it happen, I'll keep hitting Ctrl-x Ctrl-s until a save actually goes through (takes a few times).
Does anyone have any idea why this happens and how to prevent it?
Update:
(More info per request)
I'm currently on a Ruby on Rails project and have been getting the error while editing a variety of file types *.rb, *js.coffee, *js.erb, *html.erb, etc.
The files I receive the error on are always files local to my machine. I haven't tested remote files.
If I look at the *messages buffer, for every time the error message occurred, the error is prefixed with: save-buffer-2
Update 2:
Issue is encountered in multiple Emacs versions by multiple users.
Update 3:
This doesn't appear to be an Emacs specific issue as I now get the occasional "Unable to save" popup window while attempting to save files in Sublime-text editor.
This can be a bug from emacs (M-x report-emacs-bug), some issue with your filesystem (I assume this is not the case because most likely you checked if problem happens with other editors), or some process in your local setup messing with your files.
For testing if the later is the case, you could try to eval this and then reproduce the problem:
(defadvice save-buffer (around find-shenanigan activate)
(condition-case ()
ad-do-it
(error
(shell-command (format "lsof -V %s" (buffer-file-name)) "*debug-issue*"))))
What this does is every time the save operation fails, it executes a command that takes a picture of the processes that have your file opened. If you see any process, you know who investigate. man lsof will help with the details.
Note: Does the problem happen also with emacs -Q?
EDIT: if you can use sudo without password (NOPASSWD in /etc/sudoers), replace "lsof" with "sudo lsof"
EDIT: I redirected the output of the lsof to a buffer named *debug-issue*; check that buffer if error.
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.
In OS level,how can it achieve knowing something's changed(like file changing)
e.g:
In node,we can monitor a file and perform some actions while it changes
fs.watch(file_path,function(){
//do something while the file's changed;
});
can someone give me a brief intuition/idea/keyword about how it really works
one I can come up is that while I hit :w in vim ,it somehow invoke some system *fake_save_file* function,and inside this *fake_save_file* function,it dispatch some events to somewhere else
You might know that the kernel indexes the files in file system as file descriptors. File watching is achieved by listening to changes to those file descriptors. In linux inotify does that.
Whenever you open, read, write/modify or move a file, the kernel issues operations upon the file descriptor. Inotify extends the filesystem by tracking these operations and showing them to you.
The example you gave is somewhat incorrect. The fake_save_file is created by your text editor vim to store the temporary changes made unless you the user actually saves it. When you save it with :w the editor replaces your actual_save_file with a copy of fake_save_file.
As a user you would be watching your actual_save_file. This gets changed when you enter :w in vim. You will be notified as vim modified its contents.
pyinotify is might be you want.please check it.