git repo on NTFS mount

git repo on NTFS mount

[Lukas Schubert]

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'

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?

Thanks


Lukas

Re: git repo on NTFS mount

[brian m. carlson]

[-- 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 --]