symbolic/hard links system calls

spx2 has asked for the wisdom of the Perl Monks concerning the following question:

ok,i have a question regarding a certain situation involving links in typical unix filesystems from that dude randall schwartz who wrote learning perl (i hope he doenst mind me quoting his "stuff"),ok ill cut it short to the quote

" There's another rule about the links in directory listings: the inode numbers in a given directory listing refer to inodes on that same mounted volume.[] This rule ensures that if the physical medium (the diskette, perhaps) is moved to another machine, all of the directories stick together with their files. That's why you can use rename to move a file from one directory to another, but only if both directories are on the same filesystem (mounted volume). If they were on different disks, the system would have to relocate the inode's data, which is too complex an operation for a simple system call."

my question is why is it too complex for a system call, and how is this actually achieved ? where can i read this up ? cheers monks! (spx2 raises the bottle to the air in honor of all monks on perlmonks :) ) thank you

Comment on symbolic/hard links system calls

Replies are listed 'Best First'.
Re: symbolic/hard links system calls by merlyn (Sage) on Jun 14, 2007 at 16:51 UTC
`use File::Copy qw(move); move $source, $destination or die "Cannot move $source to $destination +: $!";` [download] And I don't mind you quoting me, but my mom spelled my first name with one L, so I'd appreciate you respecting her wishes. -- Randal L. Schwartz, Perl hacker	[reply] [d/l]
Re^2: symbolic/hard links system calls by naikonta (Curate) on Jun 15, 2007 at 01:34 UTC
Should the OP read the book more carefully.... A one L Randal wrote a book, A two L llama for the look, But to whom we owe it all Is the three L Larry Wall! I felt it like a kind of relaxation therapy before proceeding :-) Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!	[reply]
Re^3: symbolic/hard links system calls by halley (Prior) on Jun 15, 2007 at 13:54 UTC
Apologies to Ogden Nash, I'm sure. -- `[ e d @ h a l l e y . c c ]`	[reply]
Re^2: symbolic/hard links system calls by spx2 (Deacon) on Jun 14, 2007 at 16:56 UTC
ok fantastic, thanks randal , you the monk ! :D	[reply]
Re: symbolic/hard links system calls by kyle (Abbot) on Jun 14, 2007 at 16:53 UTC
The way to get a file from one filesystem to another is to copy it first and then unlink the original. If you "use File::Copy", there's a `move` function available to do it for you. `use File::Copy; move '/fsa/file', '/fsb/file' or die "Can't move: $!\n";` [download] From a quick glance at File::Copy, it looks as if it will use rename, if possible.	[reply] [d/l] [select]
Re: symbolic/hard links system calls by suaveant (Parson) on Jun 14, 2007 at 17:55 UTC
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)	[reply]
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 ]`	[reply]
Re: symbolic/hard links system calls by blazar (Canon) on Jun 15, 2007 at 11:39 UTC
my question is why is it too complex for a system call, and how is this actually achieved ? The reason why it is too complex for a system call is that as the name of the corresponding Perl function, rename suggests, it is actually a renaming. Just think of the file sitting there in the disk, identified by something: this something is actually called an inode, well at least in unixish terms. The filename is nothing but a name, and one file can have several of them: these are precisely the hard links. But of course a file residing in one specific device can not have a proper name referring to another one, don't you think so? (It can have a nickname... i.e. a wholly different file which has some content of its own, the content itself specifying the proper name it refers to. And these are the soft links.) how "to achieve it" has already been told you!	[reply]