Everything is a file cool!
But what about the IO namespace
Logging of some activity on to a given volume in the standard task required for most of volume level activity monitors. So we had a problem at hand, which goes as such.
At configuration time a volume+dir name will be provided to you and you will always write your log files on to that given volume. Now if the volume was to be give as c:\logdir. And some smart fellow now mounts another volume at the mount point c:\logdir your log file will now go to the newly mounted volume rather than going on to the originally configured volume.
Linux team had no simple solution to the problem. The windows team had a very simple solution that being of not accessing the journal directory via the mount point and instead using the volume identifier for the original volume. So the original underlying volume could always be accessed as
\\?\Volume{8400c6bf-7662-11d9-ab4c-806e6f6e6963}\logdir\log
This path will always log to the same volume. i.e the volume with the unique identifier Volume{8400c6bf-7662-11d9-ab4c-806e6f6e6963}
Instead C:\logdir\log.txt could go onto a totally different volume if logdir was a mount point for it. Bottom line is, Windows provides a way to access the files on a volume without going thru the mount point crossing process.
This was a very sentimental issue for me, because I always believed that everything that can be done in NT could be also easily done in Linux. But, this time it was not possible at all. It's against the UNIX semantics to the underlying volume at a given mount point. But Linux’s inability still needs to be justified by some rationale
Clearly UNIX was not designed to trouble us implementing this feature, neither was NT designed with considerations to our interests. I had to conclude on why was the feature present on one OS and not on the other.
The final conclusion is in Linux the device name space contained in the file system name space i.e. your device files are hosted on the file system as special nodes. viz /dev/sda1 is a special node on the root file system.
Its exactly the opposite way on NT i.e the file system namespace is contained within the Device Name space i.e. your file t1 resides on \\Device\HardiskVolume0\t1.txt so to access a file you go through a device and this is the only reason you can access the underlying volume in NT which is not achievable in Linux.
Think about it! In Linux /dev/sda1/f1.txt can never point to file on the volume /dev/sda1
On windows you can \device\sda1\f1.txt to point a file on hypothetical volume \device\sda1\.
And vice versa
in windows c:\com1 can never point to the device com1 (Can be done :)).
And in Linux this can be achieved simply by a device special node /dev/com1
This for me is the second most important difference between NT and UNIX second only to the synchronous VS asynchronous IO model. I think there has to be a way to arrange the IO namespace in such a way that it does have both features of the NT and the UNIX IO namespace. Until someone finds it everything will be just a file.
