2

I have a volume in Windows Server 2016 that is a target of the data deduplication role.

It works very well ~60% savings rate, with many files appearing as zero bytes on the disk. Zero bytes on disk file

The volume is shared over SMB and mounts fine on Mac, Windows and Linux clients. The latter two can use all files as normal, but the Macs can't.

On any file that appears as using zero disk space the Macs don't know how to read them. They can't be opened or read, and a copy in Finder produces Error code -36. The Finder's Error code -36: The Finder can't complete the operatino because some data in can't be read or written

On a working client, copying the file to a new one so that it hasn't been deduplicated yet allows the Mac to read it, since it now appears to use disk space. For example, doing the following on Ubuntu will get the file to lose optimization: cp original_file.csv temp && mv temp original_file.csv

Is this a problem that can be solved, or is there something wrong with macOS or the way it implements SMB?

Louis Waweru
  • 755
  • 1
  • 9
  • 29

1 Answers1

1

It sounds to me like you have found an ambiguity in the SMB specification. It seems that the Finder is seeing a file with 0Bytes and deciding that there is no use in accessing it, since it's empty. I could see myself easily making that choice in coding something in an attempt to 'optimize' the code. Is there something wrong with the Finder's implementation of SMB? Possibly, but you would have to read the spec VERY carefully to determine that! I would report the issue to Apple, since I can't imagine that it's not a bug. Hopefully it will end up on a bug list and get fixed soon.

On a side note, why would you use compression given the relatively cheap prices on storage today?

Arana
  • 31
  • 4
  • Thanks, this isn't the answer but you helped me realize what the problem is. I didn't realize the share works find when mapped to the Windows Server, but not when mapped to a linux server that is also sharing the share. – Louis Waweru Aug 08 '17 at 02:49