I recently had a git conflict, and rather than dealing with it properly, I didn't actually fix any of the conflicts, but did something like overwrite the files with another version from another clone of the repo, or moved the files out of the directory, or did a git reset --soft, or some other convoluted series of commands.
Anyway, I've been left with some files on my filesystem that I cannot delete. I cannot move them, rename them, delete them with DEL in the command line, or with RM in gitbash. The file is named:
pom.xml~9b19d48... dpom_refactor
It has 0 bytes, and I've no clue how to get rid of it. I no longer have any .git folder, so I can't use any git commands to rollback what I did. Whenever I attempt to delete/move/rename, I get the error:
Could not find this item
This is no longer located in C:\<filePath>. Verify the item's location and try again.
Any thoughts on how I could get rid of it?
This kind of invalid Windows filename could be dealt with like a nul file.
C:\> rename \\.\C:\..\pom.xml~9b19d48... dpom_refactor del.txt
C:\> del del.txt
Using the \\.\ prefix tells the high-level file I/O functions to pass the filename unparsed to the device driver
If that was to fail, only a dedicated tool (or Live Linux distro CD) would be able to mount that disk and remove the file.
Related
I have a git repository folder on a usb taken from a linux machine.
That repo had two folders with a colon (:) in their folder name (the linux distro allowed those)
All the folders in the repo were deleted and this deletion was then staged but not committed.
This repo was then copied to the aforementioned usb.
I am now on a windows machine and would like to restore the deleted files/folders.
I tried to use these commands:
"git restore ." which restored all the files which were not having a : in their name or their folder name.
"git restore --staged ." which give me this error: "error: invalid path '<foldernamewitha:>/<filename>.<ext>'"
I guess this is because windows does not allow : in names of file/folders. Is there any way around this?
Use an OS that permits : in filesystem paths or rename the paths. Them's your options.
If you're stuck on Windows you can brute-force this with core commands, find a workable replacement for the colons. Perhaps you could use url encoding?
git ls-tree -r # | sed 's,:,%3A,g' | git update-index --index-info
index-info docs
but you'd then have to reverse the process on OS's without those limitations, and no code looking for the unmangled names would find these files, so this only gets you one more step along the way to whatever you're trying to do. It's possible "just don't use Windows for whatever this is" would be best, also possible that's not an option; if this step doesn't get you there you're going to have to explain what you're trying to do here.
edit: one possibility: are you trying to reset just the paths that don't have colons in them? s,:,%3A,g to /:/d in the above sed.
We're sharing SYMLINKD files on our git project. It almost works, except git modifies our SYMLINKD files to SYMLINK files when pulled on another machine.
To be clear, on the original machine, symlink is created using the command:
mklink /D Annotations ..\..\submodules\Annotations\Assets
On the original machine, the dir cmd displays:
25/04/2018 09:52 <SYMLINKD> Annotations [..\..\submodules\Annotations\Assets]
After cloning, on the receiving machine, we get
27/04/2018 10:52 <SYMLINK> Annotations [..\..\submodules\Annotations\Assets]
As you might guess, a file target type pointing at a a directory [....\submodules\Annotations\Assets] does not work correctly.
To fix this problem we either need to:
Prevent git from modifying our symlink types.
Fix our symlinks with batch script triggered on a githook
We're going we 2, since we do not want to require all users to use a modified version of git.
My limited knowledge of batch scripting is impeding me. So far, I have looked into simply modifying the attrib of the file, using the info here:
How to get attributes of a file using batch file and https://superuser.com/questions/653951/how-to-remove-read-only-attribute-recursively-on-windows-7.
Can anyone suggest what attrib commands I need to modify the symlink?
Alternatively, I realise I can delete and recreate the symlink, but how do I get the target directory for the existing symlink short of using the dir command and parsing the path from the output?
I think it's https://github.com/git-for-windows/git/issues/1646.
To be more clear: your question appears to be a manifestation of the XY problem: the Git instance used to clone/fetch the project appears to incorrectly treat symbolic links to directories—creating symbolic links pointing to files instead. So it appears to be a bug in GfW, so instead of digging it up you've invented a workaround and ask how to make it work.
So, I'd better try help GfW maintainer and whoever reported #1646 to fix the problem. If you need a stop-gap solution, I'd say a proper way would be to go another route and script several calls to git ls-tree to figure out what the directory symlinks are (they'd have a special set of permission bits;
you may start here).
So you would traverse all the tree objects of the HEAD commit, recursively,
figuring out what the symlinks pointing at directories are and then
fixup the matching entries in the work tree by deleting them
and recreating with mklink /D or whatever creates a correct sort of
symlink.
Unfortunately, I'm afraid trying to script this using lame possibilities
of cmd.exe-s scripting facilities would be an exercise in futility.
I'd take some more "real" programming language (PowerShell as an example,
and—since you're probably a Windows shop—even a .NET would be OK).
I maintain a private Git repository with all of my config and dotfiles (.bashrc, profile.ps1, .emacs etc.).
On Windows this repository is stored under C:\git\config. Most applications expect the files to be elsewhere, so I added hard links between the repository and the expected locations.
Example
On Linux .emacs is located in ~/git/config/.emacs but emacs expects it to be at ~/.emacs. I run:
$ sudo ln -s ~/git/config/.emacs ~/.emacs
On Windows my .emacs is located in C:\git\config\.emacs, but emacs expects it to be in C:\users\ayrton\.emacs. I run:
PS> cmd /c mklink /H C:\users\ayrton\.emacs C:\git\config\.emacs
Issue
On Linux this seems to work fine: when I update the original file, the contents of the link update and everything stays in sync.
On Windows, the links break after a period of time and the files become out of sync (the file contents are different).
Why do the links break on Windows? Is there an alternative solution?
I've seen this StackOverflow post: Can't Hard Link the gitconfig File
So I’ve finally found a solution that takes the best of both: put the repo in a subdirectory, and instead of symlinks, add a configuration option for “core.worktree” to be your home directory. Now when you’re in your home directory you’re not in a git repo (so the first problem is gone), and you don’t need to deal with fragile symlinks as in the second case. You still have the minor hassle of excluding paths that you don’t want versioned (eg, the “*” in “.git/info/exclude” trick), but that’s not new.
The problem here is that the expected locations are different on Windows vs. Linux. For example, VSCode expects the user settings to be in:
Linux: $HOME/.config/Code/User/settings.json
Windows: %APPDATA%\Code\User\settings.json
Ideally I would like my repository to be platform independent. If take the core.worktree approach (e.g. make core.worktree be / or C:\, then exclude everything except specific files) I would have to maintain two copies of some configuration files when their absolute paths differ across operating systems.
Hardlinks can break if a editor opens/creates the file as a new blank file each time you save. It would not surprise me if Notepad did this because it reads the entire file into memory and has no need for the original file after it has loaded the file.
You can try to create a file symlink instead of hardlink on Windows.
I don't seem to have this problem on my home laptop with Windows XP, but then I don't do much work there.
On my work laptop, with Windows XP, I have a problem deleting directories when it has directories that contain .svn directories. When it does eventually work, I have the same issue emptying the Recycle bin. The pop-up window says "Cannot remove folder text-base: The directory is not empty" or prop-base or other folder under .svn
This continued to happen after I changed config of TortoiseSVN to stop the TSVN cache process from running and after a reboot of the system.
Multiple tries will eventually get it done. But it is a huge annoyance because there are other issues I'm trying to fix, so I'm hoping it is related.
'Connected Backup PC' also runs on the laptop and the real problem is that cygwin commands don't always work. So I keep thinking the dot files and dot directories have something to do with both problems and/or the backup or other process scanning the directories is doing it. But I've run out of ideas of what to try or how to identify the problem further.
You don't need to reboot; just open Task Manager and kill TSVNCache.exe.
This is safe, too. It's designed so you can kill it and it will automatically restart when needed.
(As a result of the auto-restart, note that browsing some SVN folders in Explorer, File-Open dialogs, etc. may cause TSVNCache.exe to restart. Keep an eye on Task Manager.)
Tortoise SVN is great but I have found that TSVNCache.exe can hold on to locks and get in the way at times. (Sometimes justified, sometimes not.) As a result, for some automated scripts I run I include commands to kill TSVNCache.exe as part of the scripts so it doesn't get in the way. That's only worth doing if it's an operation you perform often, though.
You can try a few things:
Since you are getting this error frequently, you can use handle.exe from sysinternals to check which process currently have open handles for the .svn\* directory. If handle utility tells you about any process, try stopping that process and then delete the directories.
Error while deleting from recycle bin: In simple terms, when a file is sent to recycle bin after deleting, it is not actually deleted, rather, a few manipulations are done in directory hierarchy (file system level) to avoid showing the file while browsing content of a folder. So If you happen to resolve the problem mentioned in comment#1, you will not get this error probably.
Cygwin command not working: Running a cygwin command on windows requires (in particular) cygwin1.dll, which is known to be shipped with other programs (eg: CopSsh, some version of svn clients etc...) as well. If there is any mismatch in the version of cygwin1.dll, cygwin commands won't work. Try searching for cygwin1.dll on your computer and try to resolve version conflicts (if any).
did you ever do mkpasswd and mkgroup for cygwin? If you're using cygwin from the command line you are pretty much guaranteed to have file system permissions issues. and you have to read a little to fix it.
http://cygwin.com/cygwin-ug-net/ntsec.html
Try this answer from me. Although it's given for TortioseGit instead of TortoiseSVN, the handling is the same:
disable the status cache (i.e. prevent the TSVNCache.exe from accessing the .svn folders continuously)
delete what you have to delete
enable the status cache to get updated overlays again
I have just experienced this problem (or similar)
I am using tortoise 1.6.7
To fix it I went to 'Tortoise Settings' from the tortoise context menu.
from there select "Icon Overlays" in the tree widget.
In the icon overlays page, I entered the path that was giving me angst into the "exclude paths:"and tortoise no longer holds that directory handle.
This is a directory that is often deleted by a process other than explorer.
Since what it appears that you are trying to do is export the repository from SVN, why not use the export functionality with TortoiseSVN. This removes all .svn directories from the generated 'working copy'.Cmdline: http://svnbook.red-bean.com/en/1.0/re10.html
If you want to delete all sub folders named .svn in windows
then create batch file with this content:
for /f "tokens=* delims=" %%i in ('dir /s /b /a:d *.svn') do (
rd /s /q "%%i"
)
save it in a file del_All_Dot_SVN_Folders.cmd . Run it. Your done.
Thanks to http://www.axelscript.com/2008/03/11/delete-all-svn-files-in-windows/
Remember the above code has .svn whereas the code in the link has only *svn so its better
to have the .svn to not accidentally have undesired effect.
I have been using git on windows-msysgit. Whenever I try to remove a repository completely either using explorer or using
$ git rm -rf ptp/
fatal: Not a git repository (or any of the parent directories): .git
it errors out "The data present in the reparse point buffer is invalid" or the fatal error above.
What's wrong with me/git?
Thanks in advance
To remove a git repo, just do rm -rf ptp/. That's it.
git rm is used to move items from the index [the staging area for changes / new files], not to delete git repositories.
To get rid of the git repository on Windows do this:
Win+R, Type cmd, Enter.
> cd c:/path/to/parent/of/ptp-repo
> rmdir /S /Q ptp
Or if it fails then check who locks the directory and delete it by hands from Explore.
Most likely some process holds a lock on files/dirs in your repo.
I tried to remove GIT on my windows-XP, by means of the Windows/Configuration/Software menu. After some error message (which I cannot remember), it removed all files. I checked it, and there are no files with ptp in the name left on the entire system.
A problem remained however: each time I opened windows-explorer, a nasty error message came calling for a dll file that wasn't there anymore.
When checking the registry, there were many traces to GIT left in the registry. I removed them carefully by hand, which seems to have solved the problem. This is of course a dangerous path, but I had no choice. Perhaps it is a good idea to look into the Windows-deinstallation script very carefully.
Stef Joosten
On Windows 10, try running cygwin console as admin and rm -rf the dir.
I have also just experienced this odd problem on windows 10: An empty .git folder simply would not delete and a restart of windows did not remedy it, nor did rmdir .git, nor did rm -rf .git.
Similarly to another suggestion, I used ubuntu (instead of cygwin) for windows (https://tutorials.ubuntu.com/tutorial/tutorial-ubuntu-on-windows#0) and issued an rm -rf .git, that worked perfectly
This solution should make it possible to delete any locked files and folders without installing any new programs:
Go to your Resource Monitor (in the Task Manager)
Go to the CPU tab
Search for your file in the "Associated Handles"
Now you'll see which process(es) are locking your file (it's likely explorer.exe)
Close those processes (be careful, this might delete unsaved work)
Delete your previously locked files, this should work without a problem now.
Optional: Start processes again (for explorer.exe: Go to Task Manager, File → New task → type in "explorer.exe")
This should work:
On Git Bash do:
$ git remote remove <name>
To see your remote list:
$ git remote
When I want to remove a GIT repo on Windows... i very simply delete (or move) the .git directory where the repo sits... I do this straight from Explorer... it hasn't failed me yet!
I have a third partition, on a dual boot with Windows 7 and Fedora Linux, and I realized I had a file open in vim in a terminal, and that was causing a .fuse_hidden... file to not be deletable.
When I closed the file in vim, I was able to delete the .git directory.