Use on hard-linked files?

[wmertens]

(Using 1.6.9 built from the git tag)

What happens when afsctool compresses a hardlinked file? Could it be that the other links are truncated and only the processed file gets a resource fork?

The reason I ask is because I'm noticing a bunch of files with 0 bytes that I didn't process with afsctool but maybe I processed one of their hardlinks. The odd thing is that the timestamp of the files was updated, which wouldn't fit this hypothesis, timestamps are stored in the directory, not with the inode, right?

[gingerbeardman]

I remember a 0-byte file issue with Clusters.app that I previously used for HFS+ compression.

But they never disclosed the reason. https://www.macupdate.com/app/mac/33585/clusters

[wmertens]

Hmm indeed I tried using clusters earlier today but I saw that it just sits idle, and since it was no longer supported I removed the prefpane. Then I found afsctool again.

This was before the 0 byte timestamp though :-/

[wmertens]

I should have tested it, it's not an issue:

$ ll -i test*
8703776780 -rw-r--r-- 2 wmertens 8082 Jan 10 15:17 test1
8703776780 -rw-r--r-- 2 wmertens 8082 Jan 10 15:17 test2

$ afsctool -cv test1
/path/test1:
Compression type: decmpfs xattr (3)
File size (uncompressed; reported size by Mac OS 10.6+ Finder): 8082 bytes / 8 KB (kilobytes, base-10)
File size (compressed): 2690 bytes / 3 KiB
Compression savings: 66.7%
Number of extended attributes: 0
Total size of extended attribute data: 0 bytes
Approximate total file size (compressed data fork + EA + EA overhead + file overhead): 2690 bytes / 3 KiB
Uncompressed file size reported in compressed header: 8082 bytes

$ ll -i test*
8703776780 -rw-r--r-- 2 wmertens 8082 Jan 10 15:17 test1
8703776780 -rw-r--r-- 2 wmertens 8082 Jan 10 15:17 test2

$ afsctool -l .
/path/test1
/path/test2

So it was something else. Urgh.

[RJVB]

On Thursday January 10 2019 05:35:33 Wout Mertens wrote: (Using 1.6.9 built from the git tag) What happens when afsctool compresses a hardlinked file? Could it be that the other links are truncated and only the processed file gets a resource fork? The reason I ask is because I'm noticing a bunch of files with 0 bytes that I didn't process with afsctool but maybe I processed one of their hardlinks. The odd thing is that the timestamp of the files was updated, which wouldn't fit this hypothesis, timestamps are stored in the directory, not with the inode, right?

Best thing is to test with an example file, and use -vvv to get per-file feedback. A priori these are detected from their link count in the stat struct so if you try to compress a file that links to the same inode it's skipped. I worked on that code very recently because I'm pretty certain it wasn't working as intended (and now is). It's possible of course that I introduced a regression that has yet to show itself to me in my own use. 0 bytes *on-disk* size is normal for files where the entire content fits in the DECMPFS attribute once compressed. That's why my `ll` alias contains the -s option, so ls prints the on-disk size too. However: afsctool tries very hard to preserve the timestamp, permissions, modes etc. of files it processes, even if it bails out. If you're seeing 0 file size, the file is actually empty AND its timestamp has been changed then I'm tempted to say something else caused this, even if you're only seeing it on files that have hardlinks. Of course, if you're 100% certain that nothing else can have touched these files during or after afsctool was processing on them then afsctool must be the culprit.

timestamps are stored in the directory, not with the inode, right?

A priori yes, and so are extended attributes. However, hardlinked copies (probably) all share the same copy because that's what the user should believe. Please keep me posted on this!

[RJVB]

And I should have seen your posts before hitting send on mine. Whew :)