* Olaf van der Spek <olafvds...@gmail.com> schrieb: > > Well, they're an fundamental concept which sometimes *IS* significant > > to the applications. It's very different from systems where each > > file has exactly one name (eg. DOS/Windows) or where there're just > > filesnames that point to opaque stream objects that can be virtually > > anything (eg. Plan9). > > Sometimes, indeed. This number of times should be as low as possible.
These cases aren't that rare. Windows, for example, tends to deny renames on open files, as they're also identified by the filename. (yes, there're other solutions for this problem, eg. having some internal-only inode numbering, etc). It's important to understand, that on *nix, filenames are not representing the files directly, but just a pointer to them (somewhat comparable to DNS entries), where other platforms directly use the filename as primary identification (sometimes even as primary key). This has great implications on the semantics of the filesystem. > > Why not designing an new (overlay'ing) filesystem for that ? > > Increased complexity, lower performance, little benefit. Why that ? Currently applications (try to) implement that all on their own, which needs great efforts for multiprocess synchronization. Having that in a little fileserver eases this sychronization and moves the complexity to a single point. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101231144455.ga29...@nibiru.local
