On Fri, Feb 12, 2010 at 5:41 AM, Patrick O'Callaghan <pocallaghan@xxxxxxxxx> wrote: > Since it's just a name, there are no restrictions on what it > contains, in fact it may not point at anything that actually exists, and > of course can actually create a circular structure. A Good Time Can Be Had By All, by symbolically linking a file that does not *yet* exist, but will in the future. 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. > Once the last hard link > is broken, the file disappears. Note also that the inode maintains a > count of hard links, but not of symlinks, i.e. symlinks are in some ways > second-class citizens. Actually that is not quite true. A seemingly bizarre and just about always surprising but well-documented and surprisingly useful requirement of UNIX filesystem symantics is that a file does not actually disappear until *two* things both occur: 1. The last hard link disappears. 2. The file is closed. Hilarity will ensue if you can find some way to open up a bunch of giant files on a filesystem that is running out of space, then keep them held open. No amount of trying to delete those files will cause their payload data to disappear from the filesystem - they will only disappear from the directory tree. Once you have the file open, despite its being deleted, you can continue to read and write it just like any other file. Not just no other user, but no other process of any kind - not even your own processes - will be able to locate the deleted files that you are holding open. It will be very difficult for naive sysadmins to even figure out what is going on. But the payload data will still exist on the disk, just like any other file. 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. This causes a lot of grief to those who try to create file servers that are completely faithful to UNIX filesystem semantics, especially when the server is some other kind of operating system, and not any kind of *NIX. While it can be argued that keeping deleted files around until they are closed is a completely asinine thing to do, consider how useful they are as temporary files: 1. Create your temp file. 2. Open it. 3. *Immediately* delete it - yourself - by making an unlink(2) system call. 4. Use your temp file for whatever purpose suits you. 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. > Soft links are similar to "aliases" on Windows. AFAIK Windows has no > concept analogous to hard links. Windows aliases, like Macintosh Finder Aliases, are conceptually similar to soft links, but aren't nearly as robust: Mac aliases and Windows shortcuts are just plain regular files. To follow the alias to the intended destination file, the user program has to make an API call. UNIX symlinks, however, are dereferenced entirely within the kernel; user programs don't have to do anything at all to follow them. If you try to open(2) a symlink, you'll immediately open the file it points to, and not the symlink itself. In fact a separate system call exists for the explicit purpose of reading a symlink when you *don't* want to dereference it. I think that's what "ls -l" uses, when it lists a symlink as well as the file it points to. There is some advantage to Mac aliases over Windows shortcuts and UNIX symlinks: they have the ability to hunt down the destination file no matter where it may be. Dereferencing a Mac alias will mount file servers, prompt you to insert removable media and the like, and the operating system has a facility for automagically updating the alias if the destination file has moved, provided that it is somehow able to figure out the new location. Interestingly, the Windows NTFS filesystem has full support for *NIX-style symbolic links, but the Windows operating system does not provide any manner of user interface for creating them. I think that was done for the old POSIX subsystem in Windows NT4. Back in the day, if one wanted to sell an operating system to a US government agency, it had to be POSIX certified. So both Microsoft, with the NT4 POSIX subsystem, and Apple, with A/UX, met that certification by providing POSIX implementations that they never expected the government employees to actually use. Instead the POSIX implementations did nothing more than to facilitate the sale, with the end-users running Win32 or Classic Mac OS applications on their new computers. While Microsoft doesn't really support the Windows POSIX subsystem anymore, the symbolic link support is still present in NTFS. There are I think some open source tools available for creating NTFS symbolic links, if you want to play around with them. I think the NTFS version of symbolic links are called "Joins" but my memory is hazy. I expect that the creation of an NTFS symbolic link is done with a single Win32 system call, if you can figure out how to actually call it. Well that about beats the subject entirely to death. Don Quixote -- Don Quixote de la Mancha quixote@xxxxxxxxxxxxxxxx http://www.dulcineatech.com Dulcinea Technologies Corporation: Software of Elegance and Beauty. -- 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
