April DaemonNews Is Here

Another month, another issue of DaemonNews. Highlights this month include a report from ApacheCon 2000, an interview with the NetBSD Foundation about the BSDI/Walnut Creek merger, Greg Lehey's Daemon's Advocate column, and the latest article in the "Managing Websites using Unix" series.

Re:Microsoft and Symlinks

[alangmead]

Unfortunately, he seems to fall victim to a problem similar to the "not invented here". He makes comparisions and assumptions on performance based on how the feature might be implemented under Unix, not on any hard information on how they actually are implemented. He's looking at SIS with Unix colored glasses.

Hard links have certain features and limitations that pretty much fall out of the design of the original Unix filesystems. Hard links don't automatically protect backup programs from making two copies of the same file onto the backup (or worse restoring two copies on a disk where only one fit before.) the same way they aren't automatically protected from backing up a hole in a file.

Finding identical files under unix is difficult, not because the process itself is laborious, but because Unix doesn't have a "block until file changed" system call. Checking for file access from other processes involves some sort of polling. There is no reason a non-Unix API needs to have the same ommision.

Every time I hear someone talk about SIS, they always say that they are just the same as some feature (hard links,symlinks,NetApp's .snapshot, VMS versions, etc.) but then ignore the parts where it is different. If it is similar to a lot of different things, it must be different enough from any single one of them to deserve to be looked at as its own entity.

On the other hand, it is quite possible that MS botched the implementation in any number of ways. It could poll for changed file and be a huge performance hog. The backup APIs may be insufficient and backup software may mess up backing up files that have been SIS'd. It may make each individual workstation rely on the network. (I suspect that that the 80-90% space savings are due to a whole netowork of machines sharing a common c:\windows directory)

I'm not going to redicule the feature based on some slashdot thread claiming that Microsoft reinvented symbolic links. I'm also not going to claim that it can't work well until I can see how its implemented. I'm not going to believe it works well either.

Microsoft and Symlinks

[dlc]

In the daemon's advocate [daemonnews.org] column, Greg Lehey explains Microsoft's SIS [microsoft.com] (the symlink thing [slashdot.org]) and why they aren't really the same as symbolic links. Pretty informative.

darren

Cthulhu for President! [cthulhu.org]