Copied file is 0 bytes!

29 Feb 2024

About a month ago we received a comment from a client.  They had a user who grabbed some files from their Xsan volume, dragged them to their Mac’s Desktop and ended up with 0 byte files!  The file on the san opened fine.  We found copying it with cp or rsync resulted in normal files.  The problem was not permissions (POSIX or ACLs) or extended attributes. Then we figured out that if the user duplicated the file on the san, the copy could be dragged to their Desktop and work as expected.  So we let it go as a curiosity. Then recently some others on MacAdmin Slack in #Xsan brought up the same issue, so we revisited it.

In both cases, the problem files came from a zip file that was decompressed on the Xsan volume. @roblarose noticed something about these files that we hadn’t; these files all have the compressed flag when viewed with ls -lO.  This indicates the files are compressed at the file system level.  This is a feature that first shipped with HFS+ and is supported on APFS as well. There don’t seem to be built in commands for working with this compression, but afsctool is available on Github.  This tool can compress/decompress files/folders and find compressed items for us.

Trying to decompress one of these files in place results in a error /Volumes/Xsan/volume/folders/open_en_de.srt: Decompression failed; file flags indicate file is compressed but it does not have a com.apple.decmpfs extended attribute
The file says it is compressed, but doesn’t seem to actually be.  This provides a possible explanation for what we see with the Finder.  The file appears to be compressed, but if decompression fails, I can see how we end up with a 0 byte file.  Unfortunately, the Finder doesn’t seem to catch this error.  It is also unclear at this point if ACFS (the file system used on Xsan) actually supports this type of compression.  If anyone knows, please leave a comment.

During all this we have confirmed that our backups of these files are ok.  They do not exhibit the problem.  It seems that the methods used by Archiware P5 (rsync) do not bring the problem along.  Slack user @roblarose has also confirmed that unzipping the .zip file on the san volume with The UnArchiver or unzip will result in working files.  So we have a slight change in workflow when adding these files to the san and some number of files that have this oddity.  We wanted to clean that up.  

We have confirmed that removing the compressed flag “fixes” the file.  So for each problematic file we want to run chflags nocompressed /path/to/file.  Now we need all the bad files.  Using afsctool -l </path/to/san/folder> > ~/Desktop/compressed_files.txt will output a list of all the compressed files in that folder’s entire hierarchy, one per line.  Then we can read that in with a script and fix each file.  See our GitHub for the script.

Share

Eric Hemmeter