git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Lukas Schubert <lukas.schubert@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: git repo on NTFS mount
Date: Sun, 5 Jan 2020 16:06:56 +0000	[thread overview]
Message-ID: <20200105160656.GG6570@camp.crustytoothpaste.net> (raw)
In-Reply-To: <op.0dv9xiwp1jamlk@localhost>

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

On 2020-01-05 at 00:49:56, Lukas Schubert wrote:
> Hi there,
> 
> for historical reasons, I keep the data that doesn't belong to any
> specific user on a harddisk that is formatted as NTFS. Some git
> repositories are there, too. Some time ago, I upgraded from Linux Mint 17
> to 19.2. That upgrade brought a change in data partition's mount options.
> Old:
> UUID=20D0WHATEVER	/mnt/DATA	ntfs	defaults,nls=utf8,umask=000,uid=1000,windows_names
> New: UUID=20D0WHATEVER	/DATA		ntfs	defaults,umask=007,gid=46
> 
> Now I want to initialize a new git repository
> user@xxxx:/DATA/Projects/LearnPython/wxGlade$ git init
> error: chmod on /DATA/Projects/LearnPython/wxGlade/.git/config.lock
> failed: Operation not permitted
> fatal: could not set 'core.filemode' to 'false'

The way Git writes a new config file is that it writes a file to the
side (as a lock file) and then renames it in place.  Because it works
this way, Git tries to call chmod(2) to set the permissions on that
file and when it fails, Git aborts.

You'll need to figure out how to make the chmod call not fail on that
file system, even if it does nothing.  Changing the mount operations
would be a good way to try fixing that.

> Since there already are repos on that drive, the initialization must have
> worked before. But in
> https://www.linuxquestions.org/questions/showthread.php?p=6074034#post6074034
> I've been told that using git in linux with repositories on NTFS is a
> recipe for disaster.
> 
> Given I change the mount options to what worked before the update, can I
> escape certain doom if I stick to a certain subset of git commands? Or is
> the cathastrophe inevitalbe due to subtle errors that culminate but stay
> hidden until it's too late?

NTFS isn't guaranteed to be broken on Linux, but neither do we test it.
It will probably work if you can make it do standard POSIX things,
although it will of course be less capable than a typical Linux file
system.

Assuming that Linux doesn't lie about file system operations on NTFS,
then Git will either work, or it will fail loudly.  It won't silently
eat your data, and that's all we can really promise in this case.  I
certainly encourage you to try fixing things and let us know how and if
it does work, though.

As a side note, if you're looking for a file system that can be shared
between Linux, Windows, and macOS, you may want to look into UDF, which
is used for DVDs, but can also be used for hard drives.  It supports
POSIX permissions and is therefore more functional on a typical Unix
system.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

      reply	other threads:[~2020-01-05 16:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-05  0:49 git repo on NTFS mount Lukas Schubert
2020-01-05 16:06 ` brian m. carlson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200105160656.GG6570@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=lukas.schubert@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).