I received a bunch of HTML files recently on a USB stick (FAT32), which were created on a Windows system, but with LF-line endings. I checked them in my browser (Firefox) on MacOS 10.14, and since on one of them I found a few changes to be done, I fired up my text editor and modified that file. After saving it, I tried to reload it, but Firefox refused now to show it and said that it has no permission to open this file.
I checked the file from the command line, and found that I could display the file using
fine and my changes were also present. I tried to restart Firefox, and even restarted the Mac itself, to no avail. Other browsers (Vivaldi, Chrome) also could not open the file. Looking at that directory
Finder, I saw that Finder could display a preview of all other files (y.html, z.html), but not of x.html I had modified.
Next I did a
ls -l /Volume/Stick/original
and found that all the "working" files (y, z, ...) showed their permissions as rwxrwxrwx (the unnecessary x-bit perhaps an artefact from the fact that the files were created on Windows), but the file x.html showed the permissions as rwxrwxrwx@. AFIK, the @ would indicate that the directory entry is in reality a link, but
ls did not show where it would be linked to. Doing a
stat of this file also did not provide more insight.
For experimenting a bit, I did a
mkdir /Volume/Stick/copy cp -v /Volume/Stick/original/* /Volume/Stick/copy
thereby creating a copy of those files. A
ls -l /Volume/Stick/copy/x.html
also showed the @ in the permissions in the copied file. However the copied version,
copy/x.html can be opened from any browser without problems, even the
original/x.html can not. Even after redundantly copying back the broken file with
cp -v /Volume/Stick/copy/x.html /Volume/Stick/original
the version from
original/x.html was unusable in the same way as before.
Of course I now do have a fully working version in
/Volume/Stick/copy, but I still would like to understand what has happened here, and why editing the file ruined the file, although a copy of that edited file does not have any problems.
My best guess is that the problem is somehow related to the fact that FAT32 basically maintains files according to the infamous 8.3 naming scheme from MSDOS, and some shadow entry is used to store the "real" filename; but I don't see how this could explain the behaviour I experienced, because I never so far had problems when creating files on a USB stick on the Mac.
Any ideas, how to explain the mystery?
Following the comment given by gidds, who pointed out the the
@ does not indicate a symlink here, but an extended attribute, I applied a
ls -l@ to both files (the non-working original, and the working copy). In both cases, the output was
Probably that lastuseddate was set when I edited the file. I then did an
xattr -p for this attribute, and both of them showed
69 FE DA 61 00 00 00 00 F0 9F C2 33 00 00 00 00
While I can't say whether this value is reasonable, but since the same value is shown in both files, it does not explain why one file "work" and one of them doesn't.
FOUND A FIX (but still can't understand it):
First, I found that restarting the Mac solved the problem in so far as the file can't be processed afterwards by all browsers, and also the preview in Finder looks OK. However, editing the file - or, for that matter, any other file on the USB stick - caused the problem to occur again.
After some experimentation, I found that the problem was tied to a particular text editor. I used the Cot Editor for editing the file, and with this, things get broken if the file is on a USB stick.
If, after rebooting, I edited the file using Tincta instead, everything is fine.
Further, I noticed that, once I got a broken file with the Cot Editor, I could also fix it by first copying the broken file on the command line to some other, temporary file, then erase the broken file, and finally copying it back from the temp file.
I don't know what Cot Editor is doing specially with those files, but at one point during my experiments, when I wanted to quit Cot Editor, I got a pop-up message saying: "The document x.html is on a volume that does not support permanent version storage". I have seen this message the first time and don't know, what it means, but at least it shows that there is something special about the USB volume which upsets this text editor.