Welcome to WWDC and Network File Systems. Glad to have you all here today. My name is Rusty, and I'll be your host and part-time demo monkey today. Hopefully, that'll all go well. So this session is really geared towards both admins and developers alike. So we're going to be going into what's new in our network file systems for Leopard. Start off with an overview. Then we're going to get into some more of the detail and drill down some of the features. We'll have the engineers responsible for those features come up and present to you.

And then we'll follow up with some good general information. So, before we get into the Q&A session, I noticed that there were a lot of you who had gone to the Network Home Directory's brown bag and got shut out of that. So hopefully we can kind of take some of those questions at the end of that.

So what's new? Today we have AFP as our primary network file system. We recommend this for use whether it's network home directories, personal file sharing, or workgroup serving. This is really what we promote to provide the best performance and capabilities across the board. We also provide NFS and SMB, but that's not really the focus for Tiger and for Mac OS X.

Moving forward, we want to change that. We want to make a big major shift and provide much better support for SMB and NFS so that you have the freedom to choose which is really best for your situation for your network or for your applications. But how do we get there from here? So let's take a look at pretty much why we're really favoring AFP today.

First of all, it provides the highest performance of our network file systems. It's got great copy performance. It's really favored by creative professionals in their large file use and so on. It's also secure. It provides Kerbero security for authentication. It's also secure. It provides Kerbero security for authentication.

It's also a mobile file system. What we mean by that for mobility is that it can survive sleep and wake transitions, network changes, and it provides reconnect capabilities. Of course, it has support, native support, for all of the great Mac OS X features like ACLs, extended attributes, and of course, support for applications through file manager APIs.

SMB is not quite up to par with AFP in a couple of areas. It's not providing the same level of performance that we require. It's not a mobile file system, and it doesn't have support for extended attributes or the top applications through the file manager APIs. NFS is so much similar. It doesn't have the same performance and doesn't have any security at all in today's networks, and is lacking ACL, extended attribute, and Carbon file manager support natively.

But so in Leopard, we want to really to change that, and especially with SMB. We want to make SMB a real first-class citizen as a part of a network file system in Leopard. It improves the performance. It already has the security that we need, adding mobility. It's got the ACL support already, but we're going to, to that, add support for extended attributes and all the top applications through native support through file manager APIs. Similar with NFS, we're going to go and improve its performance and add security to NFS with Kerbero. ACLs, extended attributes, and file manager support, that needs to wait for NFS version 4, and that'll be coming after Leopard.

So let's take a look at kind of where we are, the progress that we've made so far, starting with the copy performance. One of the benchmarks that we do is a finer copy performance benchmark, because that's people's main interface to the file systems for Mac OS X. We're measuring throughput in megabytes per second, and we're going to compare AFP, SMB, and NFS on Mac OS X and compare that to XBee Performance running SMB, their native network file system.

And the setup for this is a core Duo iMac, although the Mac Mini makes a really great test machine as well. Measuring over gigabit Ethernet, and we're going from a cold start, meaning this is not a cached file transfer. We're not reading just from memory. It's exercising the whole machine. And we're looking at a large file transfer, and on the Windows side, we've got a measure that's running under boot camp on the same machine.

So let's start with Tiger GM. How did we compare against XP? You can see our scale here is going to go XP, SMB, NFS, and so on, and throughput in megabytes per second. So we're really looking at the top end of this would be saturating what the disk can do on that machine.

So XP turns out a real favorable performance. It's almost over 250 megabits per second, so that's a quarter of a gigabit ethernet all by itself. SMB came in a little bit less at 29 megabytes per second. NFS was quite low for the finder copy, although in our CP and command line performance it does much better. AFP performance was nearly saturated in the disks, getting the maximum throughput from that machine.

So we made some improvements in the releases leading up to 10.4.7. We've really, we've started to work on this and to deliver with the Intel machines, we wanted to bring that out in the software updates. And so today, we've got better than XP performance with RSMB and nearly double the NFS performance. And we didn't break AFP. That was good.

So beyond 10.4.7, we're looking at, for Leopard, really, you know, Vista's coming on the scene, so we need to exceed what Vista's doing across the board, not just with AFP and SMB, and to really try and saturate the network or disk performance with all the protocols. So in the in-copy performance, there was a number of things that we learned in tuning things up that I really want to share, especially with the developers in the audience.

So optimizing performance, really for network protocols, minimizing the number of transactions you make. A lot of times when we first take a look at a new application, you find that it's really leaning on stat or the get catalog info calls a lot to find out what's happening with the files that it's dealing with.

And a lot, in many cases, there are a number of redundant calls that even if with caching we can't absorb all that and maintain good performance. A very good tool for finding out how your application is performing in this area is to use fsusage on the command line. And it'll show all of the file system transactions and the time that they take. Each one of those transactions that goes out on the wire incurs latency.

And that latency, even on gigabit networks, will slow down saving document performance or copy performance. And if you're looking at wireless, which is increasingly important, or transfers over the wide area internet, it's very, very noticeable. The second way to beat the latency game is to maximize concurrency. And in some applications, it's possible to factor the problem so that you've got multiple threads. So even if you do have to make a large number of transactions, they can be going in parallel. And especially with the servers that we have today that have multiple disks, they can handle that and turn around and beat the latency that you get over the network.

And finally, increasing the buffer sizes, especially in bulk transfer of data. There's a good call that you can use in the file system to find what is the right buffer size. You don't have to guess in the application what might be good. The file systems will report that to you through StataFS. The StataFS FIO size reports back the optimal, you know, minimum block size of transfer unit for that file system.

So what about AFP? We're looking at making a lot of improvements in SMB and NFS, but AFP, it's still number one and still the one that I know a lot of the admins are depending on. And so, as you heard, we're introducing Spotlight searching over AFP. In the seed that you have today, you can look in there, and you'll see a new servers or the volume, any mounted volume. And you can search that.

And quickly, even faster than the search that we had with Spotlight in Tiger, find information that's on the disk, any disk, on your network. So that's Spotlight Searching. It's available for AFP in the seed. It works with both personal file sharing and Mac OS X Server. And it's coming to SMB and Leopard.

AFP scalability, that's always one of the number one issues that I think we feel from customers and in terms of inquiry. I'm sure a lot of the people that were at the network home directory brown bag trying to attend that were interested in AFP scalability. There's been a lot of activities on the bulletin boards and the websites this year, so much so that I had an alternate title for this slide. AFP, it ain't so bad.

I know Nigel posted a really good tuning article on AFP548.com, and I would encourage everyone to take a look at that and pick up on some of the tips that he's provided there, because they're all very good. Some of them were so good that we're actually making them part of 10.4.7 Universal Edition. We've added new defaults to AFP Server, so it's now defaulting to 200 threads. And on the client side, we've increased the WAN quantum size to 32K. So even over slower links, it's transferring larger blocks of data at a time.

One of the ways that we measure AFP scalability in our testing is we use a test called AFP Load Test. And that it approximates a home directory workload, which is really a mix of operations heavy on the metadata side, browsing, and file transfer mixed in. And it looks somewhat like this. We started doing these measurements back in the Panther timeframe, in 10.3 GM. Looking at with a dual G5 XServe, less than a thousand operations per second in that test.

But as we were moving forward and developing Tiger, we know that with Tiger coming, the Tiger client has a much higher demand for file system access, whether it's spotlight, mail, a large number of new activities going on in the system. So we started delivering some of the updates, improvements in efficiency through that time, so that by the 1039, by this benchmark, we were at four times the level that we shipped in Panther GM.

Some further efficiency improvements came with Tiger GM, so we're up to five times there. So now we've got looking at great new hardware coming out, and we want to be able to support that as well. And we've made some estimates testing with the Mac Pros, with the Universal 1047, and we're close to 17 times Panther performance on the Dual X or G5. But we're still, even with that, we're leaving something on the table.

And we need to go beyond efficiency improvements and introduce some finer grain locking, so that we can really take advantage of the quad cores that are available in that hardware. And our goal is to get to 20X performance when we ship in Leopard on that platform. So AFP scalability, just to summarize that, improvements in efficiency, finer grain locking, and reducing the client workload whenever we can to improve the number of clients that we can support in home directory servers especially.

So to wrap up, coming online with secure NFS in Leopard, that puts us one of our major milestones on the path to NFS version 4. We're going to completely overhaul the automounter and replace it with AutoFS. So there won't be a single line of code left. Promote SMB to a first-class citizen on the platform. Give it all the features that we have in AFP. And of course, continue to improve performance and scalability on the platform and provide spotlight searching for network volumes. Now I'd like to introduce to you Brent Callaghan, who will come up and talk about secure NFS.

I talk about insecure NFS, that's the NFS we have now today in Tiger. Just to explain about what insecure NFS means, let's look at an NFS transaction where the client and the server are quite friendly towards each other, they trust each other. And each NFS request there's a thing called the credential and the header where the client explains to the server who it is, and the server just trusts that information.

The client can really invent anything it likes to go in there. And that's causing kind of a bit of a problem. It's all right in your friendly network, but in a more hostile network that's really not going to work at all. So fortunately secure NFS can fit into an NFS authentication framework that already exists.

We're just not making very good use of it with our current use of the credential. There's also a thing called the verifier that comes back from the server and this allows the server to authenticate. It's self to the client. You never quite know when you're talking to an NFS server just who that server really is. You're sending your valuable data to that server.

Is that the server you were talking to yesterday or was it some server that just popped up just to take your data? You don't really know. So fortunately this framework lets us use other kinds of security and this is where we can just plug in Kerberos. So with Kerberos authentication, the client and the server do not start off on a nice friendly basis. They do not trust each other. They are hostile towards each other. This is where the Kerberos server comes in.

Both the client and the server know and trust the Kerberos server. It's like their mutual friend. So they don't trust each other but they do trust the Kerberos server. The Kerberos server keeps all of their keys on it, although the keys never actually go across the network. Using the Kerberos server, the client and the server can negotiate a secure session. So part of the session is a session key that the client and the server can use to digitally sign the credential and the verifier. So this is really pretty secure.

So looking a little more closely at Kerberos NFS, first of all, a super user no longer has any super powers. So because you can become super user on the client does not mean that you can become any user and access their home directory. You can't do that anymore.

The only way you can really get to somebody's home directory is if you know their password and you can get their Kerberos credential. So that's really good. The next thing is we're encrypting or we're digitally signing the verifier that comes back from the server. So the server not only trusts the client, but the client can now trust that it's talking to the right server. So that's important as well.

Another thing that we get with Kerberos authentication is because we no longer send the UID and the GID across the wire anymore, we actually use the Kerberos principal name that comes when we set up this Kerberos server. So Kerberos is a very useful way to get into the Kerberos context. And the server just maps this principal name.

It looks something like an email address. Maps this to the user's UID and from that it generates the groups that the user is in. So that means if you're at home and you're user 501 on your kid's Mac and you mount your home directory from work, you will not be user 501.

You'll be the user that the server sees you when you log in at work. So that's quite nice. Finally, we're not particularly new to Kerberos NFS. This is already quite widely supported in the industry. So you can get this today, Linux 2.6, NetApp servers have it, EMC, Solaris, they all support Kerberos on NFS. So this will slot right in there.

So how do you turn it on on the server? So mostly what it comes down to is a new security option called Sec=. And if you set Sec= on your export, then you can select Kerbero as one of the options there. So the default is still Sec=Sys. So if you didn't have any security there, that's the default. Sys means trust me security.

But you probably want to use Kerbero security. So if you use Kerbero, you can set it up on the Sec= option. You can also put a list there. So you can say Sec=KRB5:Sys. And what the server says to the client here is, I prefer you use Kerbero's version 5, but if you don't support that, then you can continue to use the old trust me security.

And this is probably what you want to set up when you're initially migrating all of your clients from Tiger across to Leopard. You don't want to make it too disruptive. And at some point in the future, you just remove the Sys when you assume everybody's converted over, and off you go with a pure Kerbero solution. So that's the default.

So on the client, when the client is doing the mount, there is a sec equals option there too, but you don't really have to use it. The good news is that version 3 clients and servers will auto-negotiate what kind of security they're using. So if you just go and turn Kerbero security on on the server and the client supports it, then the client will automatically mount, will do that mount using Kerbero security.

If you do use that option, then that's really a way of asserting what security type you want. So if the server doesn't support Kerbero and you use the sec equals Kerb 5 option, then the mount will fail. So that's just a way of making sure that you've got the kind of security that you think you need. But in general, you shouldn't really have to set this option. You don't have to set it in your automounter maps or in your mount command line.

So we understand now that the Trust Me security really doesn't provide you any kind of secure authentication. And with Kerbero's version 5, we can get secure authentication. That's really good. That's a huge step. But the client and server have this session key, and they can use it for other things. So not only can they use it to digitally sign the credential on the verifier, they can use it to digitally sign the entire NFS request and reply. So as a result, we get another flavor of Kerbero security, and it's KRB5I, the I's for integrity protection.

So if you turn that on, then you can send your NFS data across a network. It may be a hostile network, comfortable in the knowledge that nobody can change your data as it goes between the client and the server. And we've actually seen this used in some networks where there weren't hostile people in the network, but there were hostile routers or hostile networkers, network routers that were dropping bits on the way, and the TCP checksum wasn't quite up to it, and we got some data corruption. So we turned on the Kerbero's integrity protection, and that really fixed the problem. Also with that key, if you're really, really paranoid, you can use KRB5P, P for privacy.

And we can use that session key to encrypt the data going between the client and the server so that nobody can see it. So the downside to that is that there is a performance cost in doing that. You'll reduce your throughput somewhat, but that's up to you to pick the kind of Kerbero security that you really think you need.

So moving on to deployment, how do you deploy secure NFS? If you're already using Kerbero in your network, for instance, if you're using Open Directory, then your clients will already have Kerbero's key set up, because that's what you need to log into Open Directory. Then on the server, all you need to do is just set up those exports you want with the KRB5 option, and off you go.

And really, you have to do nothing on the clients. If they're Leopard clients, they will auto-negotiate that Kerbero security, so you don't have to do anything on the clients. And when the users log into those clients, they'll be issued their Kerbero's keys when they log in. So deployment's really pretty easy, as long as you already have Kerbero set up in your network.

So just to summarize where we are, we took a quick look at the TrustMe security that we're currently using in Tiger. And we can look forward to the Kerberos security coming in Leopard, which will give us some strong authentication. That's what we need most. And kind of as a bonus, you'll get integrity protection or privacy, if you really need it. It's already quite widely supported. So if you're using other kinds of NFS clients and servers in your network, then we will interoperate with those.

Fairly easy to deploy if you're already using Kerberos. And unfortunately, it's not in the CD that we gave out the other day. But it will be in Leopard. So you can look forward to Kerberos coming in Leopard. So to introduce Guy Harris coming next, and he'll be introducing the new automounter coming in Leopard.

First question is, why do we have an automatter? Well, one thing is to automatically mount things. It'll mount remote file systems on demand when you refer to them, rather than having to mount a whole bunch of stuff you may never use when the system starts. And you can also use it to provide a global file system namespace. You could, for instance, if you had source code for a software development shop, you could have a mount point called releases. And under that, you might have subdirectories for each release you've put out.

They might be on different servers, but the clients wouldn't have to know that. They go to release 1.0, and there's the source to 1.0. So we have a new automounter that we'll be providing. It's a modern one, multi-threaded, more robust, faster, and it'll be based on the one in OpenSolaris.

It will do in-place mounting, none of those symlinks that trigger the mount that point off to where it's really mounted. And you take the path and run it through real path or any of the Carbon APIs that use real path. And you now have something that won't trigger the mount, so you have to undo all that, no more of that. And it will mount things from a server one at a time. If you refer to something from a server, it's not going to mount everything from that server all at once.

And here's what the Tiger Automounter looks like. It's implemented as an NFS server, so in the kernel, you have the NFS client, and if you refer to something that's under the automounter, it will go through the NFS client, which will talk to one of two NFS servers that are set up and mounted. There's the FSTab and static automounter process, which gives you things like network servers, network applications, network library, and then there's one for the NSL, which is used for network browsing.

With Leopard, instead we have a new in-kernel file system, AutoFS, based on the Solaris AutoFS, and references to network servers, network applications, or anything else that goes to the automounter will go through AutoFS, and that will talk to a Solaris-derived automount daemon, but it won't do that on every reference. It's just when it needs to mount something, it talks to the automounter, but once it's mounted, the automounter daemon is out of the box.

We also have a daemon called AutoFSd, which is new. It listens for network change events and anything else that would change what's actually being mounted, and will run the Solaris-derived automount command, which actually mounts the AutoFS on the desired targets. We can also run automount directly from the command line, but that would mainly be for testing purposes.

New Automounter will actually be able to get hold of the Kerbero credentials of the process doing the mount, so that requesting the mount, so that if the mount requires Kerbero credentials such as an AFP mount, an SMB mount, or a Kerberized NFS mount, it will be able to do the mount with the correct credentials. It won't mount as guest or anything like that. That will work in a GUI session, but it will also work if you SSH in. You'll be able to get your AFP mounts done as you rather than as guest.

The new automatter will support standard automatter maps, the RFC 2037-BIS, for those of you who know what that means. It's more to the point. It's compatible with what Linux and Solaris automatters are using, so you won't have to take your automatter maps and do an LDAP dump and run them through a script and turn them into text files and stick them onto your Macs and say, OK, go mount from this file. It'll just plug in, pick up the mounts from your LDAP or NIST server just as your other Unix boxes do.

And, after all that, we're still supporting the same old stuff. We have a -fstab and -static special maps, and that'll get you to network server, as well as static mounts like network library, network applications. And we will also support Solaris' executable maps, which is something similar to a CGI script for automounting. Instead of making a request to an LDAP or a NIST server to get the contents of the map, it will actually pass an argument to a program.

So you have the executable map, and that map might be used for a directory of items. And if you refer to one of the items in the directory, the name of the item in the directory gets passed to the executable map, and it looks in whatever data source it's written to use and returns an indication of what should be mounted there. It could be a URL, it could be a hostname, colon, NFS style, and it will mount that.

And we've added an extension to that so that you can actually do browsing on it. You can say, here's a directory, what are the names of all the items in that? And so there, you pass the executable map zero arguments, and that will tell it that just look in the data source and then print to the standard output a list of all the items that are in that directory, and those will show up in an LS or in a finder listing.

And here's a quick example of an automatter map, that executable map, that we can use to implement /home, which is a map that the directories in /home correspond to the names of users, and they give you that user's home directory. So the first thing the script does is says, was I passed zero arguments, which means it wants a listing of the users, in effect.

So it will run LDAP search against whatever your LDAP server is and say, dump out all the records for the users, and then a little bit of sed to convert that into just the names of the users. Otherwise, it was given an argument, and that argument is, in effect, the name of a user.

And so it'll take that, it'll do a query of the LDAP server, and this time it'll say, show me the entry with this user's home directory. So it'll take that user's ID and give me their home directory property, and then there's a little bit of awk that will take that home directory property and form a NFS name or URL out of it to say, go mount this. And we have a demonstration of another automatter demo.

Let me just... So we've configured it to run the new automounter by setting in /etc/host/config to set it to automount new, reboot, and the new automounter takes over.

From there, we'll need to configure automounter then to run our executable map. So within the automaster file, which is also in /etc, you can see the various mappings here where we map network servers to the -fs tab that Guy was talking about, and network public, which is our executable map, to auto public. Now auto public is a script that's going to discover NFS servers using Bonjour so that we can have ad hoc NFS.

So you can see the script. I'll make that a little bit bigger here. In this case, we've got a Ruby script that's interacting with, that's using the DNSSD service discovery library. And we walk through, if there's no arguments passed, it'll do a listing of all of the NFS servers on the subnet that are advertising over Bonjour. And if it's provided a name, in the case where you're actually trying to CD into that directory, that's when it'll go up and provide the mount record so that AutoFS can do the mount.

So we can see that. And since these are just scripts, you can just run them on the command line. It's just simple text output. So NFS Server Demo is this machine over here, Power Mac G5 running NFS and advertising its exports over Bunchor. And the next thing, if we then run AutoPublic with passing the-- The name of that server, we can see that it returns back, it just returns them out, you know, simply returns them out record through standard input to tell us where to mount.

Well, the magic of spaces. OK, here we go. How do we get back? There we go. So from Finder, you can see that we click on Public, and it's done the browsing. It's found the server demo. Click on it, mounts it, and boom, there it is. Thanks, and back to Guy.

The capabilities that we have in what's in the WWDC seed, it can mount NFS and AFP and SMB with URL equals, can mount NFS with URL, as well as mounting NFS with a standard NFS specifier. It can read standard automatter maps from files. It can read mount records from NIS or LDAP with FSTab and static. And NFS home directories work. They have to work.

That's how I do my work. Not in the seed, however, we don't yet support Kerberoz mounts. So your mounts have to be either NFS or they have to be guest AFP or SMB mounts. We don't yet have support for reading the standard maps. And you can't log in with an AFP home directory.

And because its capabilities are not all there, it's not the default in the WWDC seed. So to turn it on, there's a line in the etc.host config file that controls whether the automounter is on or off. We have a third option. You find the line that says automount equals yes, and you change it to automount equals new, all caps new, and then reboot, and the system will come up with a new automounter for testing purposes. When we ship Leopard, you will not have to do this. The new automounter will be the default, and in fact, it will be the only automounter, and it will support all the things that were listed in the top.

And in summary, it's an auto fast automounter. It's multi-threaded, so if it's waiting for some server to respond, that doesn't mean that every single reference to anything automounted hangs up behind it. It'll be mounting things in place, so you won't have to deal with these symlinks that cause your directory not to be what you think it is. No more private automount, private network.

And in summary, it's an autofast automounter. It's multi-threaded, so if it's waiting for some server to respond, that doesn't mean that every single reference to anything automounted hangs up behind it. It'll be mounting things in place, so you won't have to deal with these symlinks that cause your directory not to be what you think it is, no more private automount, private network. The automounter won't be required to access a file system once it's been mounted.

Thank you Guy. Good afternoon. Let's see if I can get started. We have many new features and enhancements coming in the Leopard release, and I'd like to go over a few of those with you today. We now support Windows 2003 straight out of the box. What I mean by that is we support the default security settings for Windows 2003.

We can now connect using port 445, so if you're firewall blocking your net bias ports, this is no longer a problem for us as we can still connect to your servers. We've added SMB signing, which prevents man-in-the-middle attacks and gives you message authentication. The Leopard client will automatically use signing if required to by the server.

Should be a note here that there is a performance impact when using SMB signing. And all of this is in your Leopard Seed today, so you can try it out. We now can reconnect with SMB. Anytime you have a connection failure, SMB will automatically attempt to reconnect to the server.

Once the connect/reconnect gets established, SMB will then attempt to reestablish the state to what it was before the connection went down. This should be a big boost for home directory users who hopefully won't even notice they had a connection failure. We will no longer prevent your systems from going to sleep.

In previous releases, if you had an SMB volume mounted, we wouldn't allow your machines to go to sleep automatically. This is due to the fact that we didn't support reconnects. All of this is also in your Leopard Seed. We don't have support for Kerbero's reconnects currently, but we will have them before we ship.

It is our goal to make SMB work and behave more like AFP. In that vein, we have added better Carbon, Cocoa, and POSIX application support. We now support open-deny modes and mandatory byte range locking. This should allow Office and other applications to work more like they do with AFP.

You can now rename or delete an open file. This is needed by many applications, but especially by Cocoa and POSIX applications. So hopefully they'll work a little bit better when dealing with SMB volumes. We have better finder interoperability. We now support create times, and we have more accurate modified times.

Previous releases, the modified times were on a two-second interval. They are now on nanoseconds. A lot of applications require accurate modified times, and you might have noticed this if you played around with the finder in SMB. We now support the finder lock bit, and we map the Windows hidden bit to the finder invisible bit.

We have complete Dropbox support now. The Dropbox may reside on a Macintosh server, a Windows server, or any Samba server. If your server is using the Access Control List, then your user will need to traverse, create, and write privileges on that Dropbox. If your server is doing POSIX permission, then your user will need to write and execute privileges to that Dropbox. We now have full Macintosh file name support. We can do this because we are now mapping the Windows Reserve characters.

So, any file name that can reside on your local file system can now reside and be used on your SMB volume. And I know that one works and it's in your seed. SMB is now working and behaving more and more like AFP, but you know what? With all these things that we've added, there still seems to be one thing missing. I'm not sure what that is. Oh yeah, we have one more thing. We still have those silly .underbar files, don't we? Not anymore. We're blowing them away in Leopard.

No more dot under bar files with SMB. Any server-- well, skip, sorry. Getting ahead of myself. We currently now support Microsoft's NTFS stream for client and the server. So any system that says they support streams no longer will need ._files. It is also our goal to work with all systems that say they support streams.

Currently, the services for Macintosh streams are fully supported. We treat all other streams as extended attributes. There is a size limit to an extended adder, so this might cause some issues with some streams. We have a one-to-one name mapping between extended attributes and streams. We've added stream support to the Samba server, so both the client and the server will be doing this name mapping. All of this code will be given back to the community, so hopefully other vendors can take these extensions and implement them.

For FAT file systems, and this will include your Tiger servers, the Leopard client will automatically revert back to using ._files, the same as your Tiger clients. So it's just something to be aware of. We do have something for upgrading. The .clean tool will convert .underbar files to their native storage format.

You can run the .clean tool against any local folder or volume. Do not run the .clean tool against any folder or volume being exported by NFS. NFS still uses ._ files and converting them might cause you some unneeded problems. If you have a non-Macintosh file system out there, the Leopard Client can help you with this conversion.

Just mount the volume with your Leopard Client and then run the .clean tool against the mounted volume. You should make sure that no other users are using that volume at the same time. And now, Rusty is going to come up and show you a quick demo of the .clean tool in action.

All right, so a lot of you have seen this kind of display. You have a SMB client connect to your server, copies a bunch of files in there, maybe fonts like this. And from Finder, instead of seeing font files, you see a lot of things that look like UNIX executable files. The reason being for that is that rather than the-- got to get to the right directory.

that a lot of the important information from those files is missing, at least from Finder's perspective. It's expected to find it in the native location, in the Finder info, as part of extended attributes, or in the resource fork. But in this case, it's set aside. In the separate .underbar file that you can see here, we can list on the command line, you can see those files that are invisible from Finder. They actually have all of the size. In a lot of these cases, the entire data of these font files is kept in the resource work, so that's where all the information is.

So what we want to do is fix that up so that when you're running your Leopard SMB client, It's not going to know what to do with these things either. So run .clean. Specify the directory you want to clean up and bam, just like that, it goes through, iterates through that entire directory hierarchy. and recovers all the information that was lost in the .underbar file and gets it back into the native location. And again, that'll be something you'll want to do not during the upgrade, but after you've migrated to Leopard Clients. Thanks. Back to George.

Okay, now when you have multiple different types of clients accessing your Leopard server, things are going to be simpler and more reliable than ever before. Leopard and Windows clients will automatically use streams without any configuration needed on any of your part. Tiger clients won't need any configuration either. That's because the Leopard Sandbook server is automatically going to convert your ._ files to their native storage format.

AFP and SMB, and this will include your Windows clients, will all now be able to share the same storage and work seamlessly together without any hassles or problems. If you have a Windows server that has an NTFS volume it's sharing, you're going to have to turn the streams option on for your Lepre clients.

There's two ways of doing this. One is to create a special file on the top level of the share, and I'm not going to read it, on top level of that share, and all your Lepre clients, when they access that share, will automatically use streams. The second method is to edit the client's configuration file.

This will cause that client to use streams on any share it comes to that says it supports streams. All modern Windows clients automatically use streams, so there's no configuration needed on their part. If you have a Tiger client in this environment, we recommend that you either leave streams turned off, use some third-party product, or preferably just switch to using a Leopard server.

In this environment, we have a Windows 2003 server, a Leopard server, and a variety of clients accessing it. They can all share the same storage. You can copy data from one server to the other. So you can take a Services for Macintosh volume running on your Windows box, copy that data to your Leopard server, turn Services for Macintosh off, and all your clients will be able to access that native storage as if it was natively stored there all along.

You can move data between clients, and all the data stays together. That's because the finder information, the resource fork, the extended attributes, and the data fork are all part of the same file. So you can move it from one system to the other, from one server to the other, and never lose any valuable information.

SMB has now become a first-class citizen on the Macintosh. To review, we now support Windows 2003 and ReConnex. We have better Carbon, Cocoa, and POSIX application support. We interop with the Finder better. We support Dropbox. We now have full Macintosh file name support, and the last little thing there, we now support Streams.