> Or, since you mention that this file is hosted on a ZFS filesystem, and I am > only aware of ZFS filesystems in file servers rather than macOS systems, > maybe the problem is in the file-serving software running on the server or a > client on your mac. If the file is on a separate file server, one thing to > try is to get to a shell on that computer, and examine the underlying file. > Can tools on the server read the file's contents? What are the contents > there?
This is a bit of an aside, but (Open)ZFS was ported to OS X/macOS a while ago, it appears as if development is ongoing: https://openzfsonosx.org/ Apple used to have a ZFS team, though clearly with Apple's decision to instead internally develop and release APFS, I am guessing that the Apple ZFS team and their work was probably disbanded, long ago. > I had baffling problems with apparent file corruption of a file written to a > ZFS Fileserver on a TrueNAS Core OS (based on BSD) connected by SMB. The > problem turned out to be that the file name on the server file system was so > long that the server's or client's SMB code couldn't handle it. For some > reason, other software on my mac had been able to write the file, with a long > name, to that same filesystem. Weird. My fix was to use the server's shell to > shorten the filename. Then all was well on the mac side. I don't claim that > this is your problem, just that there are a class of baffling problems that > have symptoms of corrupt file contents but are actually caused by file system > misbehaviour. looks like the file on my system is hosed to the point where it's not even recognized as a text file anymore. I can't read the file using vi either, vi shows an empty buffer with the message: OpenZFS isn't bug free; though the issues you described (as well as others I experienced while I worked for iXSystems with jkh et al) seem as if they're maybe not entirely surprising? SMB/CIFS got their start with Windows which was pretty constrained to around 260 characters historically for file paths, including file names. Apparently with Windows 10/11 this has been increased to around 32,767 characters? Though it's my experience that Windows, even recent variants, are just awful at non-ASCII character sets in contrast to macOS and other operating systems. Presumably SAMBA and other 3rd party CIFS/SMB implementations maybe inherited that old constraint for compatibility concerns? If you keep up with OpenZFS development, you'll note that as it was originally developed in a time before NVMe drives. A lot of contemporary storage mechanisms have different designs now that ZFS developers weren't intentionally taking advantage of because they started their work almost 25 some odd years ago (e.g. check out this interview with Allan Jude of Klara Systems: https://www.youtube.com/watch?v=BjOkWTeZJDk). Having written as much, hopefully OpenZFS will continue to evolve and improve! It's currently one of the more robust and OS agnostic filesystems in existence. There's OpenZFS on Windows too: https://openzfsonwindows.org/ and of course, FreeBSD, Linux as well as ye olde Solaris/Illumos/etc. Though AFAIK there was an effort to port it to OpenBSD, that was abandoned some years ago: https://flak.tedunangst.com/post/ZFS-on-OpenBSD (some of the issues described there seem to echo the impetus behind DragonFlyBSD's efforts instead spent on the HAMMER/HAMMER2 filesystems.)
