Win 7
cygcheck (cygwin) 3.1.7
I created some mount points (mount winname name) years ago. I've just installed a new HDD and have to change the links.
There are some links where the owner:group is "?:?" (attributes are "??????????", size is "?" and time is "?"). I can not delete these links, change owner:group or chmod. They are inaccessible and return with an error message of "cannot access 'symlink': No such file or directory" whenever an operation is tried on them. But, they are listed under 'ls'.
I can not do a umount name. The error message is:
Is there any way that I can just delete these things and start over?
Well, I just forgot about mount tables (fstab). editing /etc/fstab solved my issues.
Sorry to have wasted your time.
Related
I've got a problem with editing eclipse.ini.
My system is Arch-based Manjaro, if it'll help.
I tried with edit it with a root rights with sudo -e /snap/eclipse/current/eclipse.ini, but it said "file system is for read only". Then I tried sudo gedit /snap/eclipse/current/eclipse.ini, and then it said "You're trying to save to save the file on a read-only disk". No system reboot is helped.
So what should I do? I'm trying to make my eclipse work for a few days already XD.
I want to disable fsck from doing a file system checks (yes I am aware of it's purpose). Online it says to edit the 6th column in the /etc/fstab file.
sed -i 's/ [1-]$/ 0/g' /etc/fstab
I have tried putting it when the kickstarter files run but it doesn't actually edit the file since it is memory. Am I looking to disabling fsck incorrectly or how should I do it?
Finally figured it out. There are two things that you can do. For rhel 7 you want to fsck.mode=skip to your boot_opts line. Then to be able to enable fsck back up, you edit fsck.mode=skip from your grub files then commit those changes to your grub file. grub2-mkconfig > /boot/grub2/grub.cfg. This will reactivate the fsck.
I have to mount five of my main directories viz. (/home, /usr, /tmp, /root and /var) for a specific project. I did some googling and found out a set of commands which can be executed to mount a particular directory. The commands were as follows:
#dd if=/dev/zero of=/filesystems/tmp_fs seek=512 count=80000000 bs=1M
#mkfs.ext3 /filesystems/tmp_fs
After mounting, the entry was registered in fstab as below,
/filesystems/tmp_fs /tmp ext3 noexec,nosuid,loop 1 1
And at the last step, the directory was mounted.
I followed the same procedure for mounting all the directories specified above. In the end, I could only mount "/root" and "/tmp" directories without any errors. Rest all the three directories gave some or the other error. After mounting '/home' directory, I am getting the following error "No directory. logging in with HOME=/" and similarly after mounting '/var'
directory I got the following error "/var/lib/apt//lists No such file
or directories". Mounting of '/usr' directory caused the OS to crash as
a result of which we could not even login as root user and also some
basic commands like 'vi' and 'sudo su', to name a few were not found in
the system. ecause of these issues, the only option left was to format
the OS since we could not even revert this step because of the missing
commands.
Any help or suggestion here in the right direction would be of great help here.
Thanks for the consideration.
I am hoping that a more experienced set of eyes will find something obvious that I am missing or will be able to help me work around the errors that mv and rsync are producing. Up for the challenge?
Basic idea:
I have a bash script in which I am automating the move of files from one directory to another.
The problem:
When I run the script, periodically I get the following error from the mv command:
mv: cannot stat `/shares/directory with spaces/test file.txt': No such file or directory. The error code from the vm command is 1. Even more odd, the file move actually succeeds sometimes.
In addition, I have a branch of logic in the script that will alternately use rsync to move/copy specific files (from the same local file system source and destination as the mv command mentioned above). I get a similar error related to the stat() system call:
rsync: link_stat "/shares/directory with spaces/test file.txt" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9]
This error does not always manifest itself when the script is run. Sometimes it completes the file move without complaint, while other times it will return the error consistently when the script is run successive times.
There is one additional ingredient you should be aware of (and I am growing to suspect this as a key ingredient in my grief): the directory /shares/ is a directory that is being monitored by an installation of Dropbox -- meaning it is watched and mirrored by an installation of Dropbox. At this point, I am unable to determine if dropboxd is somehow locking the file, or the like, such that it cannot be stat-ed. To be clear, the files are eventually freed from this state without further intervention and are mv-able.
The code:
mv -v --no-clobber "${SOURCEPATH}${item}" "${DESTINATIONPATH}${item}"
More info:
The following might, or might not, be relevant:
mount indicates the filesystem is ext4
Presumably, ownership and permissions shouldn't be an issue as the script is being run by root. Especially if the file system is not fuse-based.
The base "directory" in the path (e.g. /shares/) is a symlink to another directory on the same file system.
The flavor of Linux is Debian.
Troubleshooting:
In trying to eliminate any issues with the variable expansion or their contents, I tried hardwiring the bash script like such:
mv -v --no-clobber "/shares/directory with spaces/test file.txt" "/new destination/directory with spaces/test file.txt" after verifying via ls -al that "test file.txt" existed. For reference the permissions were: -rw-r--r--
Unfortunately, this too results in the same error.
Other possible issues I could think of and what I have done to try to rule them out:
>> possible issue: slow HDD (or drive is in low power mode) or external USB drive
>> findings: The drives are all local SATA disks set to not park heads. In addition, even when forcing a consistent read from the file system, the same error happens
>> possible issue: non-Linux, NFS or fuse-based file system
>> findings: nope, source and destination are on the same local file system and mount indicates the file system is ext4
>> possible issue: white space or other unprintable chars in the file path
>> findings: verified that the source and destination paths where properly wrapped in quotes
>> possible issue: continuation issues after escaped newline (space after \ in wrapped command)
>> findings: made sure the command was all on one line, still the same error
>> possible issue: globbing (use of * in specifying the files to move)
>> findings: nope, each file is specified directly by path and name
>> possible issue: path confusion from the use of local path
>> findings: nope, file paths are fully qualified starting from /
>> possible issue: the files are not actually in the path specified
>> findings: nope, verified the file existed right prior to executing the script via ls -al
>> possible issue: somehow the --no-clobber of mv was causing issues
>> findings: nope, tried it without, same error
>> possible issue: only files created via Dropbox sync to the file system are problematic
>> findings: nope, created a local file directly via touch new-local-file.txt and it too produced the same stat() error
My analysis:
The fact that mv and rsync produce similar stat() errors leads me to believe:
there is some systemic underlying boundary case (e.g. file permissions/ownership or file busy) that is not accounted for in the bash script; or
the same bug is plaguing me in both the mv and the rsync scenarios.
Desired outcomes:
1. The root cause of the intermittent errors can be identified.
2. The root cause can be resolved or worked around.
3. The bash script can be improved to gracefully handle when the error occurs.
So, with a lot more troubleshooting I found an errant rsync statement some 200 lines earlier in the script that was conditionally executed (thus the seeming inconsistent behavior). That rsync --archive ... statement was being passed /shares/ as its source directory, therefore it effected the /shares/directory with spaces/ subdirectory. That subdirectory was the ${SOURCEPATH} of the troubling mv command mentioned in my post above.
Ultimately, it was a missing --dry-run flag on the rsync --archive ... statement that causing the trampling of the files that the script later expected to pass to mv to process.
Thanks for all who took the time to read my post. Though I am bummed to have spent my and your time on what turned out to be a bug in my script, it is reassuring to know that:
- computers are not irrational
- I am not insane
- there is not some nefarious, deep rooted bug in the linux file system
For those that stumble upon this post in the future because you are experiencing an error of cannot stat, please read my troubleshooting notes above. Much research went into that list. One of those might be your issue. If not, keep debugging, there is an explanation. Good luck!
Need help. I have been editing a text file in vi , and i was able to save the changes before but now i am getting the above error whenever i am typing command to save the file. Please help .
You can, as vi (or, more likely, vim) is saying force a write by doing:
:w!
Alternatively, write the file to an alternative location:
:w! /path/to/other/location
To check where your backup files are being written (normally):
:se backup? backupdir? backupext?
Try to touch a file in that directory and see if your Operating System gives you an error to enlighten you as to why your editor cannot write there.
Had the same problem. Tried all options as above but it did not work. Then when I checked my disk space, it was full. Once I cleared some space then I was able to write back to file again.
P.S: This was in linux.
Had the same problem. It was because I installed vimconf as root. You need to change rights of files in ~/.vim directory and change owner to your user.
sudo chmod 0750 ~/.vim
sudo chown user ~/.vim
I had this same problem. Turns out it was due to running out of disk space. try creating a file using Ex) touch test.txt. If you get a message saying touch: cannot touch test.txt: No space left on device you will need to clear up space on your disk
I don't know what the cause was, but I moved by backupdir from . to ~/.vim/backups in my .vimrc and it solved it for me:
set backupdir=~/.vim/backups
I'd imagine some sort of tool was using the folder the file I was editing it in (Visual Studio 2013, in my case), but I'm not sure.
I've fixed this with:
sudo chown {user} ~/.cache/vim/* -R
where the "{user}" field is your user-name.
from within vi, try:
:w!
:help w! gives the following information:
*:w!*
:[range]w[rite]! [++opt] {file}
Write the specified lines to {file}. Overwrite an
existing file.
In my case my disk was full.
Here are some commands to verify this and find where the disk space is being taken. In my case it was the PHP log at over 20GB.
# see general disk space usage
df -h
# see current file and directory disk space usage. You can go to / and work your way in
du -sh *
Backup location can be given in .vimrc, e.g.:
set backupdir=~/.vim/backup
You may need to create this directory yourself.
Another possibility is that you put your backups in a centralized location (e.g. /tmp) and you edited a particular file as root. Then, the backup file will be owned by root and un-writeable by you as a mere mortal later.
In this case, the suggestion above to touch /tmp/atestfile won't show the problem! You'll have write permissions, no problem, but not to the particular backup file vim is trying to write.
Remove the file as root (sudo rm).
Note that the reason w! works is because vim writes the file without writing a backup file (you're insisting that it write despite the error).
I just started using nvim and I found my issue was that my borrowed premade vimrc file had a preset source in it.
grep -rnw ~/.config/nvim/ -e backup
.config/nvim/lua/custom/vimrc:132:set backupdir=~/.backup/,/tmp/
Like others here, creating that backup directory cleared my error message (~/.backup/)