Google Backup and Sync Failure

[ylluminate]

With the new refresh of Google's Backup and Sync app we're seeing the following failure when attempting to add a folder:

What's worse is that the Pictures folder here is showing up also as 0 bytes also (is actually a symlink to a ZFS pool) and so it's just not recognizing folders on here at all.

I have also already issued: sudo zfs set com.apple.mimic_hfs=on tank/Pictures that should have taken care of the problem, but doesn't...

[ylluminate]

Well, I just had Google Drive vomit all over the place on me. It is now refusing to setup altogether after some unrecoverable errors this morning and it's request to re-set it up again:

[ylluminate]

Gotta love (and by love I mean HATE HATE HATE) Google. They've gone and added APFS support today, but apparently were daft or buttholish enough to not add support for any other file system such as ZFS:

[ylluminate]

I heard back from Google and they refuse to explicitly add support for ZFS. Apparently we have to figure out why HFS is not being spoofed properly to Backup and Sync from Google.app. Please let me know if you'd like some help in ascertaining what is going on here. I suspect we can trace this out in some fashion.

I'm not sure what to look for here, but I've run dtruss "/Applications/Backup\ and\ Sync.app/Contents/MacOS/Backup\ and\ Sync" >| output.txt 2>&1 to capture hopefully some idea of what may be going on. When I search for the volume I attempted to add (normally it's my Pictures folder stored via a symlink to the ZFS volume, but figured I'd try to add another tank as well to help with searching), I found the following two chunks:

getattrlist("/Volumes/backup_tank/crazy_name_to_test\0", 0x700006DE7B50, 0x700006DE7F58)		 = 0 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
fcntl(0x1B, 0x8, 0x700007AF48B0)		 = 0 0
fstat64(0x11, 0x700007AF48A0, 0x0)		 = 0 0
fcntl(0x1B, 0x8, 0x700007AF4900)		 = 0 0
fcntl(0x1B, 0x8, 0x700007AF48B0)		 = 0 0
fstat64(0x11, 0x700007AF48A0, 0x0)		 = 0 0
fcntl(0x1B, 0x8, 0x700007AF4970)		 = 0 0
pread(0x11, "\0", 0x1000, 0x3000)		 = 4096 0
fcntl(0x1B, 0x8, 0x700007AF4770)		 = 0 0
fcntl(0x1B, 0x8, 0x700007AF4720)		 = 0 0
fcntl(0x1B, 0x8, 0x700007AF4720)		 = 0 0
fcntl(0x1B, 0x8, 0x700007AF4720)		 = 0 0
pwrite(0x1A, "7\177\006\202\0", 0x20, 0x0)		 = 32 0
fsync(0x1A, 0x0, 0x0)		 = 0 0

...

getattrlist("/Volumes/backup_tank/crazy_name_to_test\0", 0x7FFEEFBF4CC0, 0x7FFEEFBF4D20)		 = 0 0
psynch_cvsignal(0x100356F28, 0x7D5040007D50500, 0x7D50400)		 = 258 0
psynch_cvwait(0x100356F28, 0x7D5040207D50500, 0x7D50400)		 = 0 0
getdirentries64(0x28, 0x1051F5000, 0x1000)		 = 0 0
psynch_cvsignal(0x100356F28, 0x7D5050007D50600, 0x7D50500)		 = 258 0
psynch_cvwait(0x100356F28, 0x7D5050207D50600, 0x7D50500)		 = 0 0
close_nocancel(0x28)		 = 0 0
psynch_cvsignal(0x100356F28, 0x7D5060007D50700, 0x7D50600)		 = 258 0

So I went ahead and made a test HFS filesystem in order to hunt for the same thing, but it didn't seem to yield any discernable pattern:

getattrlist("/Volumes/hfs_crazy_name_to_test\0", 0x70000A0BAB50, 0x70000A0BAF58)		 = 0 0
lstat64("/Library/Google/GoogleSoftwareUpdate\0", 0x7FFEEFBF61B8, 0x0)		 = 0 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
lstat64("/Library/Google/GoogleSoftwareUpdate\0", 0x7FFEEFBF69D8, 0x0)		 = 0 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
chmod(0x119737040, 0x1ED, 0x0)		 = 0 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
getuid(0x0, 0x0, 0x0)		 = 501 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
psynch_mutexdrop(0x109BFE070, 0x11403, 0x11300)		 = 0 0
psynch_mutexwait(0x109BFE070, 0x11403, 0x11200)		 = 70659 0
psynch_mutexdrop(0x109BFE070, 0x11503, 0x11400)		 = 0 0
psynch_mutexwait(0x109BFE070, 0x11503, 0x11300)		 = 70915 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
geteuid(0x0, 0x0, 0x0)		 = 0 0
lstat64("/Library/Google\0", 0x7FFEEFBF6158, 0x0)		 = 0 0
lstat64("/Library/Google\0", 0x7FFEEFBF6978, 0x0)		 = 0 0
chmod(0x10ED3BA90, 0x1ED, 0x0)		 = 0 0

You wouldn't happen to see anything meaningful as far as filesystem detection goes would you?

[brendonhumphrey]

Modifying zfs_vfs_getattr() to : VFSATTR_RETURN(fsap, f_fssubtype, 1); // BGH MNTTYPE_ZFS_SUBTYPE);

Causes :

1. Google backup and sync to accept ZFS filesystems for backup
2. for zfs mount | unmount commands to fail as we cant tell the FS is ZFS + other potential side effects.

Work is required to find a mechanism to replace the use of f_fssubtype.

Also maybe consider making hfs_mimic the trigger for setting f_fssubtype to 1??????

[ylluminate]

Great find there @brendonhumphrey. Hmm, yes, I'll be curious to hear some other thoughts here as well.

I like the hfs_mimic trigger; makes sense.

[brendonhumphrey]

Further experimentation has left me confused. I no longer believe the code change is needed.

Ylluminate can you please set hfs mimic to on, then export and import the pool and try the google backup utility by pointing it to a writeable directory on said pool, that's all I appear to have to do to make it work.

Which if validated would point to a different issue altogether.

You can try whatever you're currently running, but I am running master, so if it does not work for you then you might need to try that.

[Noctem]

I still experience this issue on master with the latest Google app and a dataset with HFS mimic enabled. I've resorted to syncing from an APFS drive.