Are dot files write protected in FAT FS?

[minimuck]

Hi,

the first thing I usually do is to bring a relevant file system under git control. The first few git commits
of the FAT FS worked like a charm until I detached/attached the DM42 again.
New git commits caused git to crash because .git is not writable anymore, only a hard FAT reformat helped.
Can you confirm this, and if so why is that? Any chance to remove this? I really like to track the changes
and want to be able to pull/rebase from/to the DM.

Regards, Joachim

[rprosperi]

Wow, you live under serious control...

It's possible the FAT implementation in the library doesn't support this, as it seems to be legal on actual FAT drives.

We'll have to wait to hear back from SM.

[minimuck]

nah, I am not That whole DM42/41x thing is so new to me that I don't want to accidentially remove or modify files that I would regret later on.
And git is so common to me that I don't even think about it. It is perfect to track any FS activity and keeping record of any changes you have made.

[reavy]

Git doesn’t typically meddle with or care about any permissions flags on files. However, Git can be very sensitive to file system sync times, caching, and consistency. For an extreme example, try working with a Git repository on a floppy drive. I would personally recommend not running Git directly from the mounted DM storage but keeping a copy of a repo on your local machine and then using a script to copy changes to and from the DM’s storage. You’ll save yourself a lot of headache this way.

[rprosperi]

I didn't know anything about git's timing sensitivity, but this does make perfect sense as the Flash FAT drive definitely is fairly slow for writing, so this probably is the cause. Given all that, I agree with reavy's suggestion, use git to manage a mirror of the FAT's content on the machine you use to manage stuff and you get the advantages of managed content in a way that isn't hindered but the FAT timing.

[minimuck]

All good now, I think the reason was that the FS was not completely written back on DM's exit (I should have used umount or sync instead).
Easily to be verified:

mount the DM
mkdir xxx
EXIT from the DM
remount => xxx gone

same thing with sync or umount => xxx survives

Thanks for helping me

[akaTB]

All good now, I think the reason was that the FS was not completely written back on DM's exit (I should have used umount or sync instead).
Easily to be verified:

mount the DM
mkdir xxx
EXIT from the DM
remount => xxx gone

same thing with sync or umount => xxx survives

Thanks for helping me

DM42 User Manual
v3.18a, Mar 2021
5.2.3.

Or just read that message on the display...

[reavy]

I should have asked, because properly unmounting the DM’s storage is so important. I assumed the user was already doing that

You might be able to add a Git hook to the various operations you’re using to force a sync every time. You’re back into floppy performance territory, but at least things shouldn’t break unexpectedly on you.

Edited to add: see Linus Torvalds’s various screeds on how messed up drive caching and file system syncing is in general these days.