in reply to symbolic/hard links system calls

I believe the reason it is too complex for a system call is generally that filesystems are implemented to the side of the system, so there is a lot involved in moving between filesystems that is beyond the scope of what a base call would handle. Whereas moving within the same filesystem requires very little actual work, so was deemed worthy.

I could of course be totally wrong.

                - Ant
                - Some of my best work - (1 2 3)

Replies are listed 'Best First'.
Re^2: symbolic/hard links system calls
by halley (Prior) on Jun 15, 2007 at 13:59 UTC

    The system call to rename a file is often seen and assumed to be atomic (and sometimes even guaranteed as such); that is, different processes can observe this mechanism and never see the system "halfway done" with the renaming of the file. This is pretty extraordinary if you realize how many bits of data actually do need to be updated when moving "bar/foo" to "../baz/foo".

    If the system had to transfer the whole content of the (potentially large file) from one block device to another block device, it's not likely that the system could continue to guarantee atomicity. Monitoring processes would either notice it is "half done" (file in both places or in neither place), or the process would end up waiting for a huge amount of time when all it wanted to see is whether a file existed or not.

    This whole question is a bit of a sidebar-- it's about Un*x or OS design, not about perl in the least.

    --
    [ e d @ h a l l e y . c c ]