I've been doing some mucking around with my Leopard 10.5.2 dev server and came across what I think is a bug (or at least a problem). It seems that if you have a folder on a Mac OS X Server 10.5.2 sharepoint, shared via Samba, and the folder has (certain, common) extended attributes, Vista (and possibly XP) users will get an error when they try to download the folder. The error the Vista user will get is: "Error 0x800700FE: The specified extended attribute name was invalid."
It seems that if you 1) have extended attributes on 2) a directory that 3) has a colon in the attribute's key or value, Vista will produce an error and prohibit downloading. Naturally, this is problematic, because users can't always control how EAs are applied. And just about every EA has a colon with MOSX.
It's pretty easy to duplicate. Create a folder on your Mac OS X desktop. Do a "get info" on the folder and type something in the Spotlight metadata field. Now drag the folder to a share on your Leopard server (using AFP). Over on your Vista workstation, try to download it (obviously using SMB). It should invoke the above error. If you do the same thing except substituting a file instead of a folder, you should not get the error.
I figured this out while managing a VMware virtual machine. The virtual machine called ubuntu.vmwarevm was uploaded from my Mac to my Leopard server (using AFP). Then I tried downloading it to a Vista client, but got the error. The ubuntu.vmwarevm is actually a bundle or a package, an opaque directory
[nbfa@crc-img-back 16:00:51 ~/]# exattr -l ubuntu.vmwarevm
If I created a directory on my Vista machine, I could download the components in the package, like the .vmx configuration file, virtual hard drives, etc—even though those files have the same EA.
Additionally, if I deleted the EA on the object, then added an EA with something like "color" and "red" via command line, so that the EA on the directory doesn't have a colon, Vista doesn't complain. It's a legal name for an EA.
The problem is, just about any EA created by Mac OS X will have a colon in at least the key field, because it follows the reverse-DNS convention and uses a colon to separate fields. Like Finder meta-information for example;
[nbfa@crc-img-back 17:29:41 ~/]$ exattr -l my_file.doc
com.apple.metadata:kMDItemFinderComment bplist00[hello worl
This could throw a kink into cross-platform filesharing if you have directories that have Spotlight info or other bits. Typical users won't know how to remove the metadata, or even understand that Spotlight comments are metadata. It's like how Macs and PCs have different allowable characters for names, except with extended attributes, you can't normally "see" the extra information, or it might be set without user interaction (as is the case with VMware virtual machine bundles). Moreover, if the server administrator script-o-matically whacks the EAs from files, it could cause some problems. There's a reason the VMware virtual machine bundle has an attribute not to be backed up hourly by Time Machine!
Don't forget you can use the "@" flag with the ls utility to see the extended attributes when listing files on a Mac via command line. For example,
[nbfa@crc-img-back 17:56:16 ~/Library/Virtual Machines]$ ls -l@
-rw-r--r--@ 1 nbfa 37 23846 Apr 23 17:14 my_file.doc
drwxrwxrwx@ 24 nbfa 37 816 Apr 23 13:27 ubuntu.vmwarevm
drwxrwxrwx+ 11 nbfa 37 374 Apr 23 14:29 vista.vmwarevm
Other packages, like .mpkg files, are understood by both Mac OS X and Vista as a true file, not an opaque directory or bundle. VMWare virtual machines on the other hand—directories that have the .vmwarevm extension, gain the behavior of a bundle, so that you can double-click on this directory and Fusion will launch.
 You can use the xattr tool to view extended attributes. I used a third-party tool of the same name, which I renamed exattr to differentiate the two. See http://arstechnica.com/reviews/os/macosx-10-4.ars/7 and http://dev.bignerdranch.com/public/bnr/.