{"thread":{"id":"52566","subject":"git repo on NTFS mount","startedAt":"2020-01-05T00:50:04Z","lastAt":"2020-01-05T16:07:05Z","messageCount":2,"participants":["Lukas Schubert","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"389237","messageId":"op.0dv9xiwp1jamlk@localhost","threadId":"52566","inReplyTo":null,"subject":"git repo on NTFS mount","fromName":"Lukas Schubert","fromEmail":"lukas.schubert@gmx.de","sentAt":"2020-01-05T00:49:56Z","receivedAt":"2020-01-05T00:50:04Z","isPatch":false,"sender":{"key":"lukas.schubert@gmx.de","avatar":null},"body":"Hi there,\n\nfor historical reasons, I keep the data that doesn't belong to any\nspecific user on a harddisk that is formatted as NTFS. Some git\nrepositories are there, too. Some time ago, I upgraded from Linux Mint 17\nto 19.2. That upgrade brought a change in data partition's mount options.\nOld:\nUUID=20D0WHATEVER\t/mnt/DATA\tntfs\tdefaults,nls=utf8,umask=000,uid=1000,windows_names\nNew: UUID=20D0WHATEVER\t/DATA\t\tntfs\tdefaults,umask=007,gid=46\n\nNow I want to initialize a new git repository\nuser@xxxx:/DATA/Projects/LearnPython/wxGlade$ git init\nerror: chmod on /DATA/Projects/LearnPython/wxGlade/.git/config.lock\nfailed: Operation not permitted\nfatal: could not set 'core.filemode' to 'false'\n\nSince there already are repos on that drive, the initialization must have\nworked before. But in\nhttps://www.linuxquestions.org/questions/showthread.php?p=6074034#post6074034\nI've been told that using git in linux with repositories on NTFS is a\nrecipe for disaster.\n\nGiven I change the mount options to what worked before the update, can I\nescape certain doom if I stick to a certain subset of git commands? Or is\nthe cathastrophe inevitalbe due to subtle errors that culminate but stay\nhidden until it's too late?\n\nThanks\n\n\nLukas\n"},{"id":"389253","messageId":"20200105160656.GG6570@camp.crustytoothpaste.net","threadId":"52566","inReplyTo":"op.0dv9xiwp1jamlk@localhost","subject":"Re: git repo on NTFS mount","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-01-05T16:06:56Z","receivedAt":"2020-01-05T16:07:05Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-01-05 at 00:49:56, Lukas Schubert wrote:\n> Hi there,\n> \n> for historical reasons, I keep the data that doesn't belong to any\n> specific user on a harddisk that is formatted as NTFS. Some git\n> repositories are there, too. Some time ago, I upgraded from Linux Mint 17\n> to 19.2. That upgrade brought a change in data partition's mount options.\n> Old:\n> UUID=20D0WHATEVER\t/mnt/DATA\tntfs\tdefaults,nls=utf8,umask=000,uid=1000,windows_names\n> New: UUID=20D0WHATEVER\t/DATA\t\tntfs\tdefaults,umask=007,gid=46\n> \n> Now I want to initialize a new git repository\n> user@xxxx:/DATA/Projects/LearnPython/wxGlade$ git init\n> error: chmod on /DATA/Projects/LearnPython/wxGlade/.git/config.lock\n> failed: Operation not permitted\n> fatal: could not set 'core.filemode' to 'false'\n\nThe way Git writes a new config file is that it writes a file to the\nside (as a lock file) and then renames it in place.  Because it works\nthis way, Git tries to call chmod(2) to set the permissions on that\nfile and when it fails, Git aborts.\n\nYou'll need to figure out how to make the chmod call not fail on that\nfile system, even if it does nothing.  Changing the mount operations\nwould be a good way to try fixing that.\n\n> Since there already are repos on that drive, the initialization must have\n> worked before. But in\n> https://www.linuxquestions.org/questions/showthread.php?p=6074034#post6074034\n> I've been told that using git in linux with repositories on NTFS is a\n> recipe for disaster.\n> \n> Given I change the mount options to what worked before the update, can I\n> escape certain doom if I stick to a certain subset of git commands? Or is\n> the cathastrophe inevitalbe due to subtle errors that culminate but stay\n> hidden until it's too late?\n\nNTFS isn't guaranteed to be broken on Linux, but neither do we test it.\nIt will probably work if you can make it do standard POSIX things,\nalthough it will of course be less capable than a typical Linux file\nsystem.\n\nAssuming that Linux doesn't lie about file system operations on NTFS,\nthen Git will either work, or it will fail loudly.  It won't silently\neat your data, and that's all we can really promise in this case.  I\ncertainly encourage you to try fixing things and let us know how and if\nit does work, though.\n\nAs a side note, if you're looking for a file system that can be shared\nbetween Linux, Windows, and macOS, you may want to look into UDF, which\nis used for DVDs, but can also be used for hard drives.  It supports\nPOSIX permissions and is therefore more functional on a typical Unix\nsystem.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"}]}