On Fri, Dec 31, 2010 at 3:44 PM, Enrico Weigelt <weig...@metux.de> wrote: > * 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
I mean that apps shouldn't have to know about inodes. > renames on open files, as they're also identified by the filename. Not true. Renaming a running executable works just fine, for example. > (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. I mean compared to implementing it properly in the kernel. Olaf -- 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/aanlktimzsvy_g8+r2zooz=skb0tza86kot2qb-eh8...@mail.gmail.com