Re: [Samba] Interoperability with MAC OSX clients, resource forks, xattrs
Hi, > Both methods sound fine to me. Once you've got code please feel > free to submit as a new vfs module, and we'll evaluate for inclusion > in the main code. ok, I'll try the first variant then (Streams into EA or file). It may take a moment because I haven't yet done any development within the frameworks samba provides but it's definitely feasible. Stefan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Interoperability with MAC OSX clients, resource forks, xattrs
On Sun, Jan 01, 2012 at 01:15:20PM +0100, Stefan Rompf wrote: > > The generic solution would be to enhance vfs_streams_xattr so that it stores > small streams in xattrs and large streams into files. These files should be > in > a subdirectory of the directory of the file they belong to and should have a > recognizable filename. An xattr on the main file could be used as a hint that > additional streams exist. > > The apple specific solution would be a VFS module that intercepts the one > stream OSX uses for the resource fork and store it into the .AppleDouble > subdirectory in a format compatible with the netatalk package. The module > would then be stacked with a vfs_streams module for the other streams. This > solution would allow better interoperability with the netatalk package. > > Thoughts? Both methods sound fine to me. Once you've got code please feel free to submit as a new vfs module, and we'll evaluate for inclusion in the main code. Remember you can now do this under corporate (C) if you need to if that makes submission easier. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Interoperability with MAC OSX clients, resource forks, xattrs
Hi Frank, > I'm working on a adouble backend for _Netatalk_ which will store all Mac > extra data in extended attributes. As you've noticed most filesystems limit > the maximum size of EAs, therefore the new adouble module will split Mac > ressourceforks larger than this limit into multiple EAs. even though it's getting slightly off topic now, this might also be interesting for the vfs_streams_xattr module. During my tests I realized that EAs are treated as some kind of second class citizens by the linux kernel when compared against the data of a file. You can already see it on the prototype of getxattr() that just allows to read or write the complete EA value, but not parts of it or seeking. Even worse, the kernel needs to allocate the value buffer as a contiguous block of kernel memory - up to 64k on XFS or reiserfs. This is a quite ambitious operation in kernel space and it failed several times on my test server even though it is equipped with 8G RAM and was just serving one OSX client at that time. You see these nice 'order 4 allocation failed' logs in the dmesg output then, also causing the getxattr() or setxattr() operation to fail. I don't want to discourage you - but you may have a hard time getting this idea to run stable. Stefan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Interoperability with MAC OSX clients, resource forks, xattrs
Stefan Rompf loplof.de> writes: > Thoughts? I'm working on a adouble backend for _Netatalk_ which will store all Mac extra data in extended attributes. As you've noticed most filesystems limit the maximum size of EAs, therefore the new adouble module will split Mac ressourceforks larger than this limit into multiple EAs. -f -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Interoperability with MAC OSX clients, resource forks, xattrs
Hi folks, I wish you all a happy new year! I want to migrate a fileserver for Windows und MAC OS clients with ancient versions of samba and netatalk to samba 3.6 (with a samba 4 domain controller), but this raises quite some issues. The new server should - if possible - not be running netatalk. While the package is quite mature, being able to access the same share with both CIFS and AFS yields into chaos since OSX. Netatalk saves the resource fork created by MAC clients as files into a .AppleDouble subdirectory. When connecting via CIFS, OSX uses other ways to save the resource fork. The current server is now a mixture of .AppleDouble directories and dot-underscore-files. I've tested the vfs_streams_xattr module. If alternate data streams are available, OSX saves the resource fork into a stream that is converted to an extended attribute by this module. Doesn't work - even though the share is on XFS that allows 64k per extended attribute, some resource forks are larger and cannot be saved then. vfs_streams_depot is totally unusable. While it can handle large streams and therefore resource forks, it stores them into directories named by major/minor of the device and inode of the original file. These files cannot be restored by standard unix backup tools and the linkage will also be lost if LVM f.e. changes the device node. Right now I'm trying to enable vfs_streams_xattr so that windows can store the zone information etc, but force the MAC to save the resource fork into a dot- underscore file resulting in two files (test.jpg and ._test.jpg f.e.) Not very elegant because renames on windows will lose the resource fork, but that would be acceptable. Any hints or ideas on better solutions? Also I have had some ideas on VFS modules for this purpose: The generic solution would be to enhance vfs_streams_xattr so that it stores small streams in xattrs and large streams into files. These files should be in a subdirectory of the directory of the file they belong to and should have a recognizable filename. An xattr on the main file could be used as a hint that additional streams exist. The apple specific solution would be a VFS module that intercepts the one stream OSX uses for the resource fork and store it into the .AppleDouble subdirectory in a format compatible with the netatalk package. The module would then be stacked with a vfs_streams module for the other streams. This solution would allow better interoperability with the netatalk package. Thoughts? Stefan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
