Error unable to unlink old git

TL;DR — check file permissions; on Linux?—maybe don’t use Sudo with Git!

This error is almost definitely a permissions issue. In my case, outlined herein, the problem stemmed from a blatant abuse of sudo. Let’s break it all down.

On certain occasions, it can be a strong temptation to use Sudo as a fix-for-all. In the normal process of development, Git can occasionally get hung up for reasons not outwardly evident; sometimes, rather than actually take the time to understand the complexities of Git, it’s easier to just force your way through it. Sudo, at it’s face, would seem like just another tool for coercing Git into compliance with your busy workflow. If you’ve been on the Linux command-line for any amount of time, you’ll know that Sudo is a valuable tool for ‘forcing’ certain tasks. In the case of Git, however, it’s anything but that. Here’s why…

Sudo at a Glance

From the get go, you need to understand that Linux systems limit the power of users by default. There’s your user profile, and then there’s the ROOT profile. This may not be a semantically accurate description of ROOT, but you can think of ROOT as a «super user» on your computer: a user profile that has access to anything and everything. With that said, there will be times when you need to assume the role of this super user—i.e., your user profile simply doesn’t have the permissions necessary to get something done. Here’s a classic example: there’s a file you’d like to edit, but you don’t have write access on the file (you open the file in an editor, but it doesn’t want to save). Changing file permissions aside, if you’d like to overcome this, the easiest way to get past this is to use Sudo. 

An important note: on any Linux system, there will be files that belong to you (usually located within your user folder just below /home), and there will be files that belong to ROOT (often above the ~/user folder).

Why not Sudo with Git?

We’ll take a look at what happens, but let’s start with how you might find yourself wanting to use Sudo with Git.

I don’t recall the exact cause, but I do recall that one day I was trying to check out a local branch on my local machine: I think I was looking to get back onto Master (now known outside Acquia hosting as Main) from some branch I was fooling around with. When I ran git checkout master, Git gave me some business about not having the permissions necessary to unlink files. I thought to myself, «wierd!?» and proceeded to stare at my terminal just long enough to loosely connect these permission problems with past use of Sudo completely unrelated to web work. «Could it be that my user profile somehow has lost permission to use Git?»—I pondered.

Being in the hurry that I always am, I didn’t take much time to read the actual output staring me in the face on my terminal. I said to myself, «let’s try Sudo» and see if that works: sudo git checkout master. Sure enough, I find myself on master, and I get on with my day: «sharks don’t look back because they have no necks; necks are for sheep!»

I felt somewhat accomplished for all of a few days, when suddenly the problem showed up again. And then it showed up again, and again, and again—to the point that I was suddenly using Sudo for just about everything I did with Git. Here’s a look at a more recent incident—going to pull a branch of Drupal module updates from remote, I hit the same problem:

I’m sick and tired of this… let’s figure this out.

Unlink in this case means overwrite/delete. The permission denied comment is attached to each individual file. What if I was tremendously wrong? What if this has nothing to do with my user profile having permission to use Git? What if, like the output suggests, it has everything to do with file permissions? AHA!

As with just about every other problem I’ve ever had, there’s a StackOverflow thread dealing with this. What’s the consensus there?—Git can’t overwrite the local files with whatever is coming in from remote because my user profile doesn’t own the files in question. Why wouldn’t I own the files in question? After all, the entire codebase resides under /home/terracoders/Sites. This is what happens when you use Sudo in git; per this little gem of an answer at AskUbuntu, you change the owner of whatever files you’re working with to ROOT.

Let’s go cd into the google_tag folder and see what’s going on:

Engage British accent: «What have you done!?»

Yeah. I’ll admit it. I was a dunce to use Sudo in the first place—it was a knee jerk reaction to a problem I didn’t have time to think through. But, as with all of my mistakes, I generally take a step back and remind myself it’s all part of the process. Sometimes you just have to screw it all up before you can grow as a developer. Once you remember what Sudo is actually used for, it makes perfect sense. I also gain a little solace in the fact that I’m not the only one out there to have made this mistake.

What we need here is to get the correct ownership on these files and folders. As a one off fix for this specific pull, I can cd into the parent directory for the google_tag folder and recursively change the ownership. Ironically, I’ll have to use Sudo to do it. It will look something like this:

After this quick ownership change, sure enough I was able to pull down that branch from remote. Go figure. If you’ve screwed up various files and directories the way I have, you may need to change permissions/ownership on your Drupal root (recursively—i.e., $ sudo chown -R user:group /path/to/drupal/root).

We’re beginning to scratch the surface of a much larger issue: who exactly should site files belong to? Git obviously has problems when they belong to root, but the answer here isn’t exactly cut and dry. It can depend on quite a lot of factors: i.e., where the docroot is located, whether you’re running a traditional LAMP stack, whether you’re running MAMP, and whether or not you’re using middle-men like Drush to manage your site. You’ll want to be sure to reference the documentation for your specific application.

The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

Subscribe

March 2019

Archives

• January 2023 (11)
• December 2022 (33)
• November 2022 (26)
• October 2022 (23)
• September 2022 (25)
• August 2022 (24)
• July 2022 (26)
• June 2022 (26)
• May 2022 (23)
• April 2022 (32)
• March 2022 (69)
• February 2022 (63)
• January 2022 (66)
• December 2021 (75)
• November 2021 (66)
• October 2021 (64)
• September 2021 (67)
• August 2021 (69)
• July 2021 (69)
• June 2021 (69)
• May 2021 (68)
• April 2021 (67)
• March 2021 (72)
• February 2021 (63)
• January 2021 (65)
• December 2020 (70)
• November 2020 (64)
• October 2020 (68)
• September 2020 (67)
• August 2020 (67)
• July 2020 (71)
• June 2020 (68)
• May 2020 (64)
• April 2020 (67)
• March 2020 (70)
• February 2020 (61)
• January 2020 (74)
• December 2019 (70)
• November 2019 (63)
• October 2019 (73)
• September 2019 (68)
• August 2019 (66)
• July 2019 (68)
• June 2019 (68)
• May 2019 (72)
• April 2019 (73)
• March 2019 (64)
• February 2019 (68)
• January 2019 (78)
• December 2018 (87)
• November 2018 (77)
• October 2018 (79)
• September 2018 (77)
• August 2018 (76)
• July 2018 (74)
• June 2018 (63)
• May 2018 (70)
• April 2018 (63)
• March 2018 (72)
• February 2018 (48)
• January 2018 (83)
• December 2017 (67)
• November 2017 (62)
• October 2017 (63)
• September 2017 (52)
• August 2017 (62)
• July 2017 (48)
• June 2017 (57)
• May 2017 (68)
• April 2017 (55)
• March 2017 (59)
• February 2017 (58)
• January 2017 (60)
• December 2016 (59)
• November 2016 (74)
• October 2016 (61)
• September 2016 (87)
• August 2016 (57)
• July 2016 (51)
• June 2016 (49)
• May 2016 (48)
• April 2016 (51)
• March 2016 (49)
• February 2016 (50)
• January 2016 (48)
• December 2015 (59)
• November 2015 (57)
• October 2015 (37)
• September 2015 (31)
• August 2015 (41)
• July 2015 (31)
• June 2015 (37)
• May 2015 (30)
• April 2015 (32)
• March 2015 (37)
• February 2015 (52)
• January 2015 (50)
• December 2014 (43)
• November 2014 (39)
• October 2014 (40)
• September 2014 (41)
• August 2014 (58)
• July 2014 (32)
• June 2014 (23)
• May 2014 (38)
• April 2014 (105)
• March 2014 (145)
• February 2014 (81)
• January 2014 (56)
• December 2013 (58)
• November 2013 (32)
• October 2013 (26)
• September 2013 (26)
• August 2013 (54)
• July 2013 (47)
• June 2013 (41)
• May 2013 (33)
• April 2013 (41)
• March 2013 (50)
• February 2013 (47)
• January 2013 (55)
• December 2012 (32)
• November 2012 (23)
• October 2012 (37)
• September 2012 (52)
• August 2012 (46)
• July 2012 (40)
• June 2012 (30)
• May 2012 (27)
• April 2012 (30)
• March 2012 (29)
• February 2012 (32)
• January 2012 (25)
• December 2011 (38)
• November 2011 (28)
• October 2011 (46)
• September 2011 (63)
• August 2011 (35)
• July 2011 (24)
• June 2011 (24)
• May 2011 (24)
• April 2011 (29)
• March 2011 (50)
• February 2011 (48)
• January 2011 (18)
• December 2010 (5)
• November 2010 (18)
• October 2010 (22)
• September 2010 (29)
• August 2010 (24)
• July 2010 (27)
• June 2010 (29)
• May 2010 (25)
• April 2010 (23)
• March 2010 (10)
• February 2010 (6)
• January 2010 (16)
• December 2009 (12)
• November 2009 (3)
• October 2009 (11)
• September 2009 (21)
• August 2009 (11)
• July 2009 (11)
• June 2009 (5)
• May 2009 (12)
• April 2009 (20)
• November 22 (1)

My Flickr Stream

Pages

All categories

Email Subscription

During git mv (rename): “unable to unlink old” “invalid argument”

Posted by jpluimers on 2019/03/20

I had an error when doing a rename (mv) in git “unable to unlink old” “invalid argument”. This appeared to be a process having a lock on that file.

In my case, this was a bit hard to track down (I used Process Explorer for it), as the culprit was SourceTree running git in the background to keep an eye on changes in the repository because it has a file system watcher on the repository tree and a different process was writing log files in the same directory structure.

Can you still follow? I had a hard time so here it is in manageable bits:

1. By default SourceTree has a file system watcher on your repositories
2. If that watcher fires, SourceTree runs a background git process to get the current state of the repository
3. If you perform UI actions, SourceTree runs a foreground git process to perform the action
4. SourceTree does not have a mechanism to wait for the background git process to finish before running the foreground process
5. I had had another process running that logged into a relative directory that happened to be within the repository tree (but using files excluded by .gitignore)

Basically SourceTree should do two things:

• keep track of the background process and not fire a foreground one
• do not start the background process for files excluded by .gitignore

I tracked down what happened using these tips:

Источник

firstByte()

TL;DR — check file permissions; on Linux?—maybe don’t use Sudo with Git!

This error is almost definitely a permissions issue. In my case, outlined herein, the problem stemmed from a blatant abuse of sudo. Let’s break it all down.

On certain occasions, it can be a strong temptation to use Sudo as a fix-for-all. In the normal process of development, Git can occasionally get hung up for reasons not outwardly evident; sometimes, rather than actually take the time to understand the complexities of Git, it’s easier to just force your way through it. Sudo, at it’s face, would seem like just another tool for coercing Git into compliance with your busy workflow. If you’ve been on the Linux command-line for any amount of time, you’ll know that Sudo is a valuable tool for ‘forcing’ certain tasks. In the case of Git, however, it’s anything but that. Here’s why.

Sudo at a Glance

From the get go, you need to understand that Linux systems limit the power of users by default. There’s your user profile, and then there’s the ROOT profile. This may not be a semantically accurate description of ROOT, but you can think of ROOT as a «super user» on your computer: a user profile that has access to anything and everything. With that said, there will be times when you need to assume the role of this super user—i.e., your user profile simply doesn’t have the permissions necessary to get something done. Here’s a classic example: there’s a file you’d like to edit, but you don’t have write access on the file (you open the file in an editor, but it doesn’t want to save). Changing file permissions aside, if you’d like to overcome this, the easiest way to get past this is to use Sudo.

An important note: on any Linux system, there will be files that belong to you (usually located within your user folder just below /home), and there will be files that belong to ROOT (often above the

Why not Sudo with Git?

We’ll take a look at what happens, but let’s start with how you might find yourself wanting to use Sudo with Git.

I don’t recall the exact cause, but I do recall that one day I was trying to check out a local branch on my local machine: I think I was looking to get back onto Master (now known outside Acquia hosting as Main) from some branch I was fooling around with. When I ran git checkout master, Git gave me some business about not having the permissions necessary to unlink files. I thought to myself, «wierd!?» and proceeded to stare at my terminal just long enough to loosely connect these permission problems with past use of Sudo completely unrelated to web work. «Could it be that my user profile somehow has lost permission to use Git?»—I pondered.

Being in the hurry that I always am, I didn’t take much time to read the actual output staring me in the face on my terminal. I said to myself, «let’s try Sudo» and see if that works: sudo git checkout master. Sure enough, I find myself on master, and I get on with my day: «sharks don’t look back because they have no necks; necks are for sheep!»

I felt somewhat accomplished for all of a few days, when suddenly the problem showed up again. And then it showed up again, and again, and again—to the point that I was suddenly using Sudo for just about everything I did with Git. Here’s a look at a more recent incident—going to pull a branch of Drupal module updates from remote, I hit the same problem:

Git. why hast though forsaken me?

I’m sick and tired of this. let’s figure this out.

If you’re using GitKraken for workflow management, you’ll get a similar error to what you see on the command-line. Arguably, «could not open ‘/pathto/file’ for writing: Permission denied» is a bit more descriptive. Good on GitKraken! I don’t use this application as much as I should!

Unlink in this case means overwrite/delete. The permission denied comment is attached to each individual file. What if I was tremendously wrong? What if this has nothing to do with my user profile having permission to use Git? What if, like the output suggests, it has everything to do with file permissions? AHA!

As with just about every other problem I’ve ever had, there’s a StackOverflow thread dealing with this. What’s the consensus there?—Git can’t overwrite the local files with whatever is coming in from remote because my user profile doesn’t own the files in question. Why wouldn’t I own the files in question? After all, the entire codebase resides under /home/terracoders/Sites. This is what happens when you use Sudo in git; per this little gem of an answer at AskUbuntu, you change the owner of whatever files you’re working with to ROOT.

Let’s go cd into the google_tag folder and see what’s going on:

. and. there you have it!

Engage British accent: «What have you done!?»

Yeah. I’ll admit it. I was a dunce to use Sudo in the first place—it was a knee jerk reaction to a problem I didn’t have time to think through. But, as with all of my mistakes, I generally take a step back and remind myself it’s all part of the process. Sometimes you just have to screw it all up before you can grow as a developer. Once you remember what Sudo is actually used for, it makes perfect sense. I also gain a little solace in the fact that I’m not the only one out there to have made this mistake.

What we need here is to get the correct ownership on these files and folders. As a one off fix for this specific pull, I can cd into the parent directory for the google_tag folder and recursively change the ownership. Ironically, I’ll have to use Sudo to do it. It will look something like this:

Problem solved!

Источник

Posted by jpluimers on 2019/03/20

This entry was posted on 2019/03/20 at 06:00 and is filed under Development, DVCS — Distributed Version Control, git, Source Code Management.
You can follow any responses to this entry through the RSS 2.0 feed.

You can leave a response, or trackback from your own site.