Mac: Folder Icons "icon?" leads to error

[warmup72]

I´m using gocryptfs v1.6.1 on osx 10.14.3
Problem:
If you try to copy an directory with folder icon gocryptfs prints the Error -36
"Some data in "Icon?" couldn´t be read"
Only the directory is copied and no files in it.
It is not possible to delete the empty folder (Errro 100006)
After a new mounting i can es the "icon?" file an delete it

It´s also not possible to set an folder icon!

[warmup72]

Okay this Problem is only reproducable, if the icns-File which you set to the folder is greater.
For example an icns with 120kb works but an icns 450kb doesn´t work!

[rfjakob]

Hmm, -36 on MacOS is EINPROGRESS:

#define	EINPROGRESS	36		/* Operation now in progress */

[warmup72]

No it is definitiv not in progress.
This an error message. The gocryptfs-Process terminates.
After restart the icon?-file has 0 byte

German Error-Message:
Der Finder konnte diesen Vorgang nicht abschließen, da einige Daten in „Icon?“ nicht gelesen oder geschrieben werden konnten.
(Fehler: -36)

The debug-Trace:
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Dispatch 2: LOOKUP, NodeId: 6. names: [._Icon
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Serialize 2: LOOKUP code: OK value: {NodeId: 0 Generation=0 EntryValid=1.000 AttrValid=0.000 Attr={M00 SZ=0 L=0 0:0 0 0:0 A 0.000000000 M 0.000000000 C 0.000000000}}
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Dispatch 4: ACCESS, NodeId: 7. data: {w}
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Serialize 4: ACCESS code: OK value:
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Dispatch 2: SETXATTR, NodeId: 7. data: {sz 32 f0} names: [com.apple.FinderInfo] 53 bytes
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Serialize 2: SETXATTR code: OK value:
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Dispatch 4: GETATTR, NodeId: 7. data:
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Serialize 4: GETATTR code: OK value: {A1.000000000 {M0100644 SZ=0 L=1 501:20 0 0:12895472697 A 1552830050.322778369 M 1552830050.322778369 C 1552830050.324227862}}
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Dispatch 2: ACCESS, NodeId: 7. data: {w}
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Serialize 2: ACCESS code: OK value:
Mar 17 14:40:50 Simons-MBP gocryptfs[33507]: go-fuse: Failed to read from fuse conn: 5=input/output error

[rfjakob]

Wow, the gocryptfs process crashes!

Can you mount like

gocryptfs -fg -nosyslog

and see if you get a panic message?

[warmup72]

The message in the terminal is the same
2019/03/17 14:54:02 Failed to read from fuse conn: 5=input/output error

[warmup72]

Didn´t know how to help now - If you need reports or other testings let me now!

[warmup72]

It seems to be some more issues with the Icons. After some days of using small Icons with 150kb max size in some folders the ?icon file disappear :-( and it´s not possible so set up a new Folder-Icon.

[warmup72]

I´ve seen that e.g. in Boxcryptor the icon? file isn´t crypted.
Maybe this would be a way to fix it?!?

[rfjakob]

Hmm no, not encrypting the folder icon sounds pretty dangerous, as the folder icon may be sensitive in itself

[warmup72]

Okay, this makes sense.
I would like to use gocryptfs for my data, but this icon-problem makes it uncertain for me, because of lossing icons after some days. Something must happen in this time because I can find no way to set up a new icon in this folders!
Do You have an idea to slow this issue?

[atYuguo]

I also have this problem, and getting error:

cp: /XXX/Icon\r: could not copy extended attributes to ./Icon\r: Argument list too long

when I try to copy the "Icon?" file in terminal. It seems being caused by the attribute com.apple.ResourceFork, which in my case very large:

ls -l@
-rw-r--r--@    1 XXX  XXX      0 May 19 17:09 Icon?
	com.apple.FinderInfo	   32
	com.apple.ResourceFork	1368085

. Maybe related to this issue: 0x09/hfsfuse#5 .

[atYuguo]

This seems related to the fuse.MAX_KERNEL_WRITE value in server.go of go-fuse package, which is 128 * 1024. However, simply enlarge this value doesn't solve the problem and can lead to file corruption.

An workaround is adding
mOpts.Options = append(mOpts.Options, "auto_xattr")
to mount.go, which makes the use of ._ files to save xattr.

[atYuguo]

Increasing XATTR_SIZE_MAX in internal/syscallcompat/sys_common.go and MAX_KERNEL_WRITE in fuse/server.go simultaneously increases com.apple.ResourceFork acceptable size.

What interesting is, if I try to write very large extended attribute to a exist file in the plain folder, there's still an error but it won't crash the file system like cp:

xattr -w testattr "$(dd if=/dev/zero bs=1048576 count=1|tr '\0' a)" abc
1+0 records in
1+0 records out
1048576 bytes transferred in 0.099079 secs (10583217 bytes/sec)
zsh: argument list too long: xattr

I now believe this is an upstream bug, see hanwen/go-fuse#362 .