Don Quixote de la Mancha wrote: > The "ln -s" command requires the path of the file to which the link > will point, and the path of the link itself. But it doesn't care one > whit whether the linked-to file actually exists. If you can supply a > path to it, you could symbolically link to anywhere. Add to that that you actually have to specify the first path from the point of view of the second one (important if it is a relative path). For example: cd /tmp ln -s passwd /etc/passwd2 now you have /etc/passwd2 linking to /etc/passwd (called "passwd"), and /tmp has not been involved at all. > I think the "lsof" > command file show that you have an un-named file open, but other than > reporting which filesystem it is part of, I don't think the actual > location of the file can be discovered in any way. Hmm? >From lsof: konsole 27162 rragusa 12u REG 8,8 55885008 1446680 /tmp/kde-rragusa/konsoleqbJrwb.tmp (deleted) I also think you can regain access to the file content if you use /proc/<pid>/fd/<fdnum>. > The cool thing about doing it this way, is that no matter how your > program should exit, your temp file will really and truly disappear > once you quit. Because the kernel takes care of closing open files > for your when your process exits, if you crash, or take some kind of > unexpected path to termination, you can be sure that that file will be > totally gone once your program terminates. > > That is much, much harder to ensure on systems where one cannot delete > open files. On those systems, you have to ensure that you delete your > file *after* you are done with it, even if you crash or take some > weird error handling pathway to termination. Otherwise you will > eventually end up with a bunch of unwanted temp files all over the > place. There is much bigger advantage. You can delete (and so recreate) executables and libraries which are running. This is the fundamental trick which creates the difference between "yum update glibc" on Linux and "please reboot" on Windows. -- Roberto Ragusa mail at robertoragusa.it -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
