Fix corruption of first byte in AFP_AfpInfo stream/xattr in Samba
#17 Updated by Andrew Walker over 1 year ago
- File osx_xattr_write.pcap added
I encountered problems with original streams_xattr and the revisions to trans2.c (i.e. https://github.com/freenas/samba/pull/59):
Steps to reproduce:
1) generate file with large ADS (6MB or more) on FreeNAS server as follows: "cat [large file] | setextattr -i user DosStream.large_xattr:$DATA' [test file]"
2) mount smb share from OSX 10.13 client, "cd /Volumes/SHARE", and "xattr -p large_xattr [test file] | wc -c" to get size of xattr. Compare with size reported locally on freenas server "getextattr -q user 'DosStream.large_xattr:$DATA' [test file] | wc -c"
3) copy test file to Desktop of OSX client and verify size.
4) copy test file from Desktop of OSX client back to SMB share and verify size.
Step (2) on my OSX client showed length of ADS truncated to 1.0MB.
Step (3) Copy on Desktop showed length of ADS truncated to 1.0MB
Step (4) New copy on FreeNAS server showed length of ADS truncated to 4KB.
Pcap of (4) attached to ticket.
#21 Updated by John Hixson over 1 year ago
Andrew & I are working on this. We have determined this to be a Mac OS issue. It may not be a big deal but we're still digging into this. I don't know if this is a release blocker yet or not, since Andrews testing methodology isn't a very good one and I'm working on some better testing tools for this. Large EA's are confirmed working on windows. I'm sure Andrew will post more as we find more ;-) This problem occurs with or without the previous vfs_streams_xattr code.
#23 Updated by John Hixson over 1 year ago
So there isn't really a problem here. Large EA's work fine. The only "problem" that happens is when a file with a large EA over what is a predefined size is copied to the local file system, it gets truncated. This isn't the general use case and this has worked this way all along. I don't even think this can be classified as a bug. I think we are good to go here and there are no more show stoppers.