I remember that years ago I read about how there was a new syscall in Linux for instantaneous copying of files (cloning) but now I cannot find it. Does it really exist?
The closest thing I found was:
https://man7.org/linux/man-pages/man2/copy_file_range.2.html
Related
Total newbie here and have no idea on what I'm doing.
I have installed ubuntu on windows can open bash from windows now.
I have also downloaded burrow-wheeler aligner from the Sourceforge: https://sourceforge.net/projects/bio-bwa/files/
From there I tried extracting the bz2 file. And I added the extracted folder into PATH
but when I type in bwa on bash, it says bwa: command not found
I'm a total beginner and want to get started with bioinformatics. I performed the aforementioned steps because that's how I setup conda to work on windows cmd.
What am I doing wrong?
In the subsystem, almost everything remains the same in your scenario just as an Ubuntu system, then you just follow the Readme file of this repository: lh3/bwa. Since the repo in Sourceforge seems to have been archived for a long time, you'd better use the newer alternative on Github.
Trying to run a shell script in Git Bash. This particular script requires the Rcpp and RcppArmadillo packages. (creating an R package implemented in C++) Because I am on a Windows system I had to install Rtools40. Upon execution of the sh command I get the error:
fatal error - cygheap base mismatch detected - 0x180316408/0x180317408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
What I've tried:
Following the instructions in the error message. However, a search for cygwin1.dll comes up empty. Additionally, I have never installed Cygwin on my machine.
Updating R, Rtools40, and Git for Windows to the latest versions. This was much needed (apparently Windows doesn't update these programs automatically sigh) but it did not resolve the error message.
Turning off ASLR protections in Windows Security settings as described in this post and this post.
Deleting duplicate msys-2.0.dll files from my drive. This ultimately worked. I will post the solution in detail as an answer to this question.
Hope this helps anyone who, like me, has been sifting through the many posts that don't fully answer this question.
So here's how I solved this problem. From what I understand, the error message in Git Bash is outdated and deceptive. It references Cygwin, but Git Bash actually uses MSYS2, not Cygwin. So instead of searching for cygwin1.dll, I needed to search my drive for msys-2.0.dll. This file was present in two locations: Git\usr\bin and rtools40\SOMETHING (I don't remember the exact path, but it was associated with Rtools40). As per the directions in the error message, I deleted the version that was older, which happened to be the one associated with Rtools40. That left only one version of msys-2.0.dll on my drive, and the sh command then executed in Git Bash with no issues.
What I'm still confused about: Why hasn't the error message in Git Bash been updated? What's the difference between Cygwin and MSYS2? I know they both impose the UNIX environment on Windows, but are there advantages or disadvantages to one or the other? In the long run, if I want to execute scripts through the command line, is Git Bash sustainable, or should I just create a Linux partition on my machine?
I came across a post on GitHub that mentioned that if you are running into this issue after getting a "Resource temporarily unavailable" error, then the issue is likely that you are running 32-bit version of Git. Install Git 64 bit, and your issue should go away
This question already has answers here:
how do I clone files with colons in the filename
(4 answers)
Closed 7 years ago.
So, I'm working on a component to my company's project in which we are using git as our version control. After I finished my task on the project, I needed to send my code in for review.
The problem is, I'm working on a Windows machine with perl files names on the remote git branch that something similar to "filename::123.pm". So what Windows does when I checkout this branch is just delete them from my local branch, and all file names with a :: in them are gone. Since these are important files, this is an issue for my additions on the local branch and cannot be merged since then the important perl files are gone.
How do I avoid this?
I wanted to try something like ignore the specific files for a git clone of the repo, so when I checkout they are ignored anyways and not removed, but this is impossible. Another thing I wanted to do was clone on a VM running linux and work from there to do commits. Well the cloning is super slow, and that isn't an option either.
What is my best option for working with this repo where the filenames are invalid for a Windows machine to read? And no, renaming the files isn't going to work since so there is so much more work to be done if we did that.
Surely you must use git sparse-checkout feature that permit to checkout only some directories and in your case ignore directories with not supported files.
Example :
http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/
I have a Mercurial repository that is located on a NAS (Buffalo TeraStation). It is mounted on a Ubuntu machine and is mapped onto a Windows 7 machine.
I have previously been able to clone, update, etc. from both the Linux machine and the Windows machine, but now am having problems. Too many changes have been made (updating versions of hg, thg, etc.) to identify a specific point where things started to fail.
I can read and write files from both machines from/to the NAS. I can use "cp" to copy entire repositories, but if I attempt to clone using hg (or thg) it fails.
When cloning an existing (in the NAS) repository to the Ubuntu machine, all of the files copy over, but the operation is aborted with the message:
abort: Operation not permitted: (repository_path)/.hg/store/.phaseroots-94sdvj
[command returned code 255 Thu Jul 30 17:39:45 2015
When cloning an exiting (in the NAS) repository to the Windows machine, the cloning hangs (with no files transferred).
I have tried various [trusted] settings to no avail.
I have tried performing the hg clone command manually and it works properly when done with "sudo". However, the cloned repository then is owned by "root".
I'm pretty sure this is a permissions problem, but have run out of ideas. Any guidance would be appreciated!
One thing can think of is support for hardlinks on the NAS you are using.
For example some of the versions of Mercurial had problems with windows shares. For more information here.
I have no explanation for the problem on the Linux machine, but the problems on the Windows machine might be caused by this exact setup (cloning from a Linux drive to a Windows machine).
Years ago, I had similar problems (although with different error messages) when pushing from my Windows machine to repositories on a shared (Linux) NAS drive - see the link for more details.
But that was over five years ago and I didn't try it anymore since then, though.
I'm reinstalling everything on my machine, and amongst those is Cygwin. I'm trying to avoid reinstallation, partly because I don't even know what it is that I've installed. Can I just move the Cygwin directory from one machine to another and expect everything to work, or are there some other important settings that I need to move as well?
As far as I saw, it's pretty self-contained, but one never knows.
Yep! Go for it. You won't encounter any problems.
You can just copy the entire cygwin directory to your new machine, open up the cygwin shell and everything (as long as you are only calling cygwin-internal programs and stuff that's within the path) will just work as if you you are working on your old machine.
The only thing you'll loose is the directory where the "already downloaded and compressed" packages for a possible re-installation are stored. Fortunately this directory is optional, so no problem for migration to another platform. You could copy that directory as well, but most likely all the packages that you have are outdated anyways and a run of setup.exe would fetch the new versions anyway...
Btw - since someone said exactly the opposite some real-life experience: I use this feature quite often with success. I've copied my cygwin dir to USB-sticks and used it on friends computers. I also copied it to the laptop of my fiance when we go to holidays and take a laptop with us.
It always worked without any problems....
The short answer is: No, you can't copy the whole Cygwin folder. You just copy the configuration files(bash files, vim file, etc.) you need.
The long answer is: If you copy the whole Cygwin folder, it may work in some case, and may not in some other case.
The reason is: you will lose linux file mode when copying files on Windows. And that will cause a lot of troubles. However, you may not have the troubles when you use Cygwin just like a common Windows Program(which means you don't care file mode and anything related), and run it as Windows Administrator(which is not required when Cygwin is installed as usual).
BTW: you can export the packages you installed by cygcheck.exe -c and install them on the new Cygwin. You can also install/update Cygwin packages by Cygwin's setup-x86_64.exe in command line like:
setup-x86_64.exe -q -P package1,package2,package3
No, you have to reinstall it from the cygwin installer, sorry!
Most importantly you'll want to copy everything from your home directory (default is c:/cygwin/home/) especially anything w/ a "." in front of the filename.
As for individual application preferences, etc., you may lose those -- but if you do the reinstall while you still have access to your old machine -- you can probably get to 90% of your previous install without too much trouble.
My experience with copying from one cygwin64 (I don't think there is a difference) to another machine is that all of the symbolic links got crushed:
As an example:
What used to be /usr/bin/cc -> /usr/bin/gcc.exe (or something like that)
After the copy /usr/bin/cc became a text file containing the string:
!<symlink>/usr/bin/gcc.exe
My method of copy was merely cp -r /cygwin/c/cygwin64 <dest>
My dest was a FAT32 FS, but I don't think that had anything to do with it.
There were also characters 0x00 and 0xFF sprinkled among many of these 'text' files so that they appeared to be binary.