New OS X uses Windows file sharing by default
arstechnica.com
arstechnica.com
The predominant form of extension is an "info level". Somewhat analogous to a data structure like that returned from stat, the numeric info level controls what structure is returned (or supplied). Microsoft had a tendency to add new info levels that correspond to whatever the in-kernel data structures were in a particular release rather than longer term good design.
The general chattiness comes from their terrible clients like Windows Explorer (akin to Finder for Mac folk). I once did a test opening a zip file using using Explorer. If you hand crafted the requests it would have 5 of them - open the file, get the size, read the zip directory from the end of the file, close it. Windows XP sent 1,500 requests and waited synchronously for each one to finish. Windows Vista sent 3,000 but the majority were asynchronous so the total elapsed time was similar.
I worked on WAN accelerators for a while where you can cache, read ahead and write behind, in order to provide LAN performance despite going over WAN links. In one example a 75kb Word memo was opened over a simulated link between Indonesia and California. It took over two minutes - while instantaneous with a WAN accelerator. The I/O block size with SMB is 64kb so they could have got the entire file in two reads, but didn't.
If anyone is curious about what it was like writing a SMB server in the second half of the nineties I wrote about it at http://www.rogerbinns.com/visionfs.html
Backwards compatibility and layers of indirection.
Microsoft has always made great efforts for backwards compatibility - Raymond Chen's blog is a good source of stories. Quite simply if you upgraded Windows and apps stopped working then you'd blame Windows. Of course it is almost always the apps relying on undocumented behaviour, ignoring documentation, relying on implementation artifacts etc. This means a lot of code to detect and work around problems in other components. For a networked filesystem client the simplest way is sending lots of requests and picking results of interest based on what comes back. Networked filesystem servers also work around client problems in various ways - eg they may return smaller block sizes than the client requested because it is known to have occasional problems. All of this builds up layers and layers of workarounds, workarounds to workarounds, having to test against OS/2 etc. SMB2 was an attempt to wipe the slate clean (no more OS/2!) but of course the crud starts building up again.
Explorer isn't a program that displays files and directories despite appearances. There are layers and layers of abstractions, parts provided by COM etc. The code that knows it wants to display the listing of a zip file is many layers away from the code that generates network requests. It is always easier to write code that does more than strictly needed than the absolute minimum necessary.
But Riverbed's SMB implementation was done by people who didn't understand it, and who had a dangerous attitude. Essentially a WAN optimizer is looking at commands and responses going by and doing a beneficial man in the middle attack based on that data. One technical issue is to decide how you handle the unknown - eg a client or server speaking a dialect you haven't tested, or a command you haven't seen before/developed support for. Our attitude was always that it invalidated any caches, and worst case would disable acceleration on that connection. Riverbed just let it fly by.
An example of how that breaks things is that there is something similar to an ioctl to set ranges of a file to be zeroed out. Riverbed didn't know about that, and would keep returning the old cached contents. Similarly they didn't know about alternate data streams, and especially how they are named which breaks a naive filename caching implementation. At one point I sat down and came up with 5 separate demonstrations of how Riverbed corrupt data (ie 5 different areas of the protocol they messed up). The first one got published and Riverbed threatened to sue, as there was some Oracle inspired clause in their legal agreements! Our lawyers were chickens and that was the last of it.
My own view is that customer data is sacrosanct and I made sure we always did the right thing. They played fast and loose. However most people would blame Microsoft if there are issues rather than realising it was Riverbed's attitude causing corruption.
Riverbed did many other things right. They didn't get acquired like most in the industry, so they didn't have to deal with being squelched by an acquirer. Their marketing focussed a lot on the low end - when people already have two devices they are likely to buy more of the same (sunk cost fallacy). And they did TCP only (we did IP and TCP). TCP only makes it far easier to configure, load balance and do auto-discovery.
Should've leaked it. Data corruption is a bitch of a problem for anyone hit by it.
This is not the reason. Time Machine does support hard links, legacy Mac metadata, and other Unix features. It does this by writing all the data into large blobs (a sparse bundle) with an embedded filesystem of its choosing (i.e. HFS+). It can use any destination filesystem for the blobs, including FAT.
Edit -- I stand corrected! It does in fact link folders as well. Also: http://xkcd.com/981/
OP seems to refer to how the Time Machine destination backup file is chunked when using a sparsebundle, such that individual chunks can be updated in isolation, which is how Time Machine came to support network backups. Previously, Time Machine's destination file was a monolithic disk image that had to be updated in whole, which would be unrealistic for network backups.
At a filesystem level, a sparsebundle is just a directory and the chunks are individual data files, which the OS coalesces into a single logical file. Sparsebundles appear as individual "files" in the Finder but you can right click to see the individual chunk files. A sparsebundle is effectively a "blob" as GP states, since it is designed to contain arbitrary data, and since it's implemented with the most rudimentary filesystem components it works across platforms as GP also states.
But when discussing network transfers it makes sense to think if it as a simple collection files rather than a "blob." (OP describes the chunks as "blocks" but that implies hard drive blocks which is not the case.)
http://bukowskiforum.com/threads/16-bit-intel-8088-chip.2791...
IBM sold a version of our stuff that was called LanServer for Macintosh so back then Macs and AFP were covered!
It was quite a popular product at the time. Although I never enjoyed working on Macs I thought that AFP was pretty cool. We all had "Inside AppleTalk" pretty much memorised - what a great book.
Fortunately OS X does not use Samba as their SMB2 client.
Setting that up with kerberos is... not fun (speaking from the solaris/linux/aix side of things).
Not that smb would be better for most unixes mind you, just that nfsv4 is its own version of hell in some ways.
Every time I connect with AFP, my CPU would spike to 100% under Ubuntu.
What this thing is saying SMB2 support has been added ( since Mountain Lion does not support SMB2 ) and seems to have been simultaneously made the default for connecting to servers that support it ( hopefully only if you don't explicitly specify what to use and presumably the SMB server on OS X Mavericks does )
You have to assume that the majority of Apple's users are home/edu/SMB users, who don't have centralised infrastructure.
They just want to share files between each other, or from a small NAS. Those who have Macs in an enterprise environment likely have a working solution via other methods.
SMB isn't so much better as more widely supported.
So there is no built-in way to share your external drives connected to Mac Mini on network if they are NTFS formatted.
There are many people shipping Samba on an appliance containing proprietary software, there is no problem doing that with GPLv3 code.
No religious objection. The problem for me with GPLv3 is that it is not compatible with (privately) signed code. If it is possible to run unsigned code on my appliance then my proprietary code would not be secure, putting the entire business in jeopardy. If you can square this circle then I'd love to use it.
I'd be interested to see a list of shipping appliances (meaning not open hardware platforms) with GPLv3 if you know of any.
Your code is still under the full protection of the law. And no signing mechanism will prevent a competitor from simply dumping the flash and reading your code off there, if they really want to - if anything this is probably easier than running their own code on the system. So I don't see what using the GPLv3 changes.
If you're really paranoid, how about running samba in a chroot/jail/etc. where it has access to the data files it needs to serve/store, but not your code? (Your code can operate on the same data from outside the chroot). As long as you make it possible for the user to upgrade samba (which should be fine - you don't care what code runs inside this chroot, because it only has access to the same files the user could access via samba anyway, so the samba that runs in the chroot doesn't have to be signed) you're compliant with the GPL but haven't exposed the rest of your system.
>law
If it is a straight rip-off then the law should protect (at least in the west), but if it were just used (for learning or adapting from) then it could be exceedingly hard to prove or even know about. I suppose what I would be most worried about is if it were leaked such that anyone could use it on any platform without paying. Who would buy an apple TV if you could run it off your raspberry pi? (I know the analogy doesn't quite work-- aTV is decent value as hardware-- but as a start up I will have higher costs so higher prices).
>flash dump
This is why you encrypt the private data on your flash :) Decryption codes can be stored in the processor (it's been a while since I looked at the system- I'll have to look again, but it seemed solid). So that means they'd have to either de-solder the RAM while somehow keeping it freezing cold too, or use an electron microscope or something on the CPU. If they are that capable then I'm sure they could just rewrite the code themselves without my 'help'. I'm not sure how much security compilation would offer, and if the details of that matter, that's something I should look into further. But the above seems pretty solid AFAICT.
>samba in a chroot/jail/etc
Thanks! This is a great idea. IIRC it is possible to break out of a chroot, but (IIRC again) not BSD jails.. so that could be a great option down the line if I am able to use BSD. It adds a fair amount of complexity legally (although it seems sound at first thought) and technically though (can they be hacked?), so perhaps one for later.
There are many appliances shipping with GPLv3 Samba, Netgear, Drobo, IOmega, Synology, just off the top of my head.
Of course none of these are trying to control what the customer does with the appliance.
If you want to control what customers do with their own hardware, write your own SMB3 server. Good luck with that..
I'm not at liberty to name them as I am the NAS boxes as most of them are not forthcoming about their use of Samba to anyone but their customers (to whom they provide replaceable source code of course), whereas the NAS vendors are well known users of GPLv3 Samba.
You seem to be under the impression that avoiding GPLv3 code prevents competitors from buying our box and rendering it down to components, including your precious software, and figuring out any trade secrets you may have.
This is a strange and incorrect impression.
If you genuinely want to use Samba in your proprietary appliance, email me (I'm easy to find). I help companies do this every day as part of my job.
You won't be able to use Samba outside of the terms of GPLv3 of course, but most companies not requiring DRM seem to be perfectly comfortable with that.