I would like to use Git for a software project which resides inside an encfs enctrypted drive mounted via Dokan (Windows environment). The Encryption of the files works just fine, unfortunately Git does not seem to like working in this environment. When initializing the Git repository I encounter the error message:
error: could not commit config file w:/djangodance/.git/config
When committing I encounter this - disk is writeable and quota is not exceeded:
fatal: Repository has been updated, but unable to write new_index file. Check that disk is not full or quota is not exceeded...
So far I have learned that Git does not seem to like certain drive-mounting-setups. This article (mounting remote filesystem via sshfs) proposes a workaround option (-oworkaround=rename).
My questions:
Did I locate the source of the problem correctly?
Is there some similar setup for Dokan which works with Git?
Is there a different approach which could satisfy on-the-fly encryption using Windows? I'd rather not use TrueCrypt since it is not as useful in combination with Dropbox.
Thank you for any hint!
Dokany is a fork of Dokan. It is very active by the maintainers and the community. It is now know as the main solution for writing driver and porting FUSE to Windows with the same code.
It also have the fix that you would be interested:
https://github.com/dokan-dev/dokany/pull/39
There was a problem with MoveFileEx. Without the fix this API fails with "permission denied" because the target file is opened and cannot be deleted.
Now the git command works via dokan!
The latest release of Dokan appears to be nearly three years ago. I don't imagine you'll get much support with it, even from the community.
You may want to consider using Bitlocker, a full-drive encryption system. Or possibly Encrypting Filesystem to encrypt your development directory. Both of these options are included in recent versions of Windows, and should be fully supported by Microsoft.
Related
I hope I can get some help here as SO UX is better than Mercurial mail list.
I've been happily using Mercurial at home for years. I am also using it with Bitbucket Cloud for a couple of more serious (but still hobby) projects.
Last year I switched my team at work from SVN (company hosted) to Hg (self-hosted, with the central repo on a network location). We are all in Windows. Since then, we're continuously having problems with severe central repository corruption, which can only be resolved using backup, e.g.:
% hg verify --verbose
repository uses revlog format 1
checking changesets
checking manifests
manifest#92: unknown parent 1 ef0f96d78ab6 of ef0f96d78ab6
manifest#92: reading delta ef0f96d78ab6: integrity check failed on
00manifest.i:88
manifest#93: unknown parent 1 e336adb3580b of e336adb3580b
manifest#93: reading delta e336adb3580b: integrity check failed on 00manifest.i:89
manifest#94: reading delta 7243aebd542b: unknown compression type '\x08'
manifest#95: reading delta 899e4507ca01: unpack requires a string argument of length 12
manifest#96: reading delta 12d4d930da4f: Manifest had an entry with a zero-length filename.
...
Some people say we shouldn't use a network share for the central repository, due to problems with locking. Others explain that Mercurial doesn't use those locks, and network shares should work fine, unless there are problems with the file system.
Considering the latter, I wonder if I could somehow debug our installation without asking the company to provide a server for hg. I don't know much about the configuration we are using, but here is what I see. The directory is accessible via a Windows network path: \\domain.com\path\path\our-directory. Inside, we created a directory called root where .hg resides. In .hgrc, the path is accordingly
[paths]
default = \\domain.com\path\path\our-directory\root
Our network directory is backed up (by the company). Hg version is 4.9.
I have had a similar experience with a similar setup.
First thing to note is that I thought older HG versions definitely did have some problems when run over Windows network file shares, so make sure your version is current. (That was years ago, IIRC, so this may be unlikely to be the root cause of your present issue).
Secondly, in my case these problems seemed to be compounded from running HG from within a virtual machine. Instead I now run an [hg serve][1] instance on a PC which is not virtualized, and hit that with the various HG clients. No more problems.
It appeared that if the connection between the PC running hg serve and the file server was more reliable than from where I ran hg as a client, this avoided the problem. Apparently the HTTP connection hg serve uses to the client is itself more reliable.
I can't say that is a definitive solution because I never found a root cause. But this seems to have avoided any more corruption for quite some time.
Note that hg serve is built right into the standard hg command line tool, you can run it from anywhere easily, and it doesn't have to run on the same server where the physical repository is stored. So in my case I use it quite casually; (obviously) you might need to coordinate with your IT people if you need something more robust.
I'm new to Git, and setting up a new repository on one of my own windows servers on my local network, with a view to being able to share source code with another developer on my network.
I have installed Git on my local windows PC, and have created a local repository for one of my existing projects.
I have also set up a shared folder on \myserver\Git Repository\
I have done a commit to the local repository, and am now trying to push that to the shared repository on the server.
I am not 100% sure what format I should be using for my URL, but the most promising error I can get is:
Pushing to file://myserver/Git%20Repository/Inhouse/File%20Comparer/.git
fatal: 'C:/Program Files (x86)/Git/Git Repository/Inhouse/File Comparer/.git' does not appear to be a git repository
fatal: Could not read from remote repository.
Why it is looking in program files folder, I have no idea.
I'm trying to keep things simple (to start of at least), and so have been avoiding using any other protocols.
I've tried googling, to find URL examples, but I just can't seem to get past this error about Got looking for the repository in the program files folder.
Any ideas?
Thanks In advance.
Maya
Got it working!
Instead of googling Git+local network share, I specifically added "windows" to my search too, as all the other information I was finding applied mostly to Linux servers.
This link helped the most:
http://elegantcode.com/2011/06/18/git-on-windows-creating-a-network-shared-central-repository/
I still didn't manage to get the //myserver/myshare/myprjectrepo working, so I mapped the share to a drive letter, and used R:/myprojectrepo instead. All working now.
On my home laptop with Windows 7 x64 (NTFS) some of mercurial repositories become stuck after unknown reason. The problem is when I try to run hg log or hg diff:
Can't access file
D:\user\my-hg-repo-root-path\='FRX'
In same time, icoming, pull, update, push, add, commit work well.
So, last several days i live without history or diff preview on the home laptop.
I've not found any reason for such a problem, as same as what FRX means. Do you know the reason of this problem?
PagerExtension?
That's where this ='FRX' might be coming from. Look at your ~/.hgrc.
It looks like this is a file that has been created by some windows application (from http://www.file-extension.com/files/FRX/: "As a binary form file, the FRX file extension can be found working with Visual Basic.") probably during an execution of VB programs, and it could be possible that you do not have the read rights on this file.
If this file is not important for you, I'd suggest to remove it from the working directory, maybe using admin rights.
I have a project that I am building using cygwin as an env. This weekend, I tried to do a standard git pull, one that has worked hundreds of times before, and I get this message.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
/usr/bin/ssh.exe: error while loading shared libraries: cygssp-0.dll: cannot open shared object file: No such file or directory
I'm a bit confused since this has never happened before. I googled "cygssp-0.dll" and found that it is some .dll file, specifically I looked here.
I tried the first option, and got to this step
enter "regsvr32 /u cygssp-0.dll" in the command line
and I got the message
The module "cygssp-0.dll" failed to load.
Make sure the binary is stored at the specific path or debug it to check for problems with the binary or dependent .DLL files.
The specific module could not be found.
At this point, I am thoroughly confused, and not all too keen to start reinstalling windows just yet. I've tried re installing cygwin.. does anybody have any ideas on what to do?
EDIT : I have already attempted to run setup-x86_64.exe several times, in an attempt to re-install something from the cygwin side.
Turn your antivirus off of silent mode or turn off heuristics. It's just deleting the file without telling you. libssp is getting deleted because it's a security library that does things to the call stack that antivirus programs don't like. (Specifically, it adds canaries, random values inserted into the stack that are meant to guard against some buffer overflow attacks. However, an antivirus that isn't coded to handle stack canary insertion will see it as a buffer overflow attack itself.)
Had the same issue today while trying to do push via Cygwin's git via ssh.
The solution is to reinstall or update Cygwin, as missing library will be redownloaded and put in proper place. Be sure that your antivirus software isn't removing it again, so disable everything that might delete it, and/or whitelist cygssp-0.dll location. As of today they're located under:
cygwin_root\bin\cygssp-0.dll
cygwin_root\usr\i686-pc-cygwin\sys-root\usr\bin\cygssp-0.dll
(second path only for 64 bit distribution of Cygwin)
I am a Mac-based (10.8) web developer, trying to work with other Windows-based developers. They are using SVN, although most of them do not check out files to local repositories. They mostly edit the file on the local server via Explorer, and then use TortoiseSVN shell enhancement to right-click and "commit" what they just edited.
I cannot seem to do this, as my preferred SVN tool Versions (as well as Dreamweaver CS6) require access with the SVN, HTTP, etc. protocols. I get errors trying to use the file system.
So, I am trying the command line, navigating to the file I need to edit, open it, edit, save. I can run svn status on the directory and I see the file status as "M". If I try svn commit -m "updated" myflie.css or similar, I get an error:
svn: Unable to open an ra_local session to URL
svn: Local URL 'file://webstage-01/svn/repository/fc-dev/assets/css' contains unsupported hostname
I looked in the .svn folder "entries" file an see this:
10
dir
20788
file://webstage-01/svn/repository/fc-dev/assets/css
file://webstage-01/svn/repository
2012-06-26T16:08:10.220007Z
20747
JSmith
So it looks like that's where it's getting the path from, which is not a valid MacOS or Unix path.
Suggestions?
It sounds like the local server is already a checked out working directory that everyone is sharing. This is the completely wrong and awful way to do Subversion. In the end, you have no idea who is making the change because they're all using the same client. Plus, there's no guarantee that working clients use the same format of the working directory. If someone has a version 1.6 TortoiseSVN on their system, they could damage that working copy.
The correct way is for everyone to checkout a local copy of what's in that Subversion repository to their local machine (Windows or Mac), and then do their changes there and check it in. You won't have the issue of someone messing up that directory. You know who is making the changes. You won't have an issue of what happens if two people try to make the same changes at the same time. It's the way Subversion is suppose to work.
The Mac has the Subversion command line client. (Assuming you're using Mountain Lion -- the latest release) You need to install XCode (free from the Mac App store), and then in XCode, install the command line tools. Look at the on line Subversion manual and learn how to do the checkout in Subversion, create your own working directory, and check in from that.
There are many options if you want a Mac OS X GUI Subversion client. I highly recommend you look at Pathfinder](http://cocoatech.com/pathfinder/). It has a built in Subversion GUI client, but it also has many Finder enhancements that make it an excellent Finder replacement -- especially for power users. It's $40, but I think it's worth it just for the built in Terminal client.
I don't think you can do that. The svn folders on "local server" were created by a platform-specific tool like TortoiseSVN on Windows. Obviously it will have paths, etc. specific to Windows. You will need to checkout separately and make commits.
Also, BTW, set the EOL property to 'native' so that you do not run into cross-platform EOL issues.