home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / linux / 22572 < prev    next >
Encoding:
Text File  |  1993-01-03  |  2.9 KB  |  75 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
  3. From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
  4. Subject: Re: BUG of feature: cannot move `foo' accross file systems
  5. Message-ID: <1993Jan3.214155.25253@klaava.Helsinki.FI>
  6. Organization: University of Helsinki
  7. References: <1992Dec31.172305.1930@klaava.Helsinki.FI> <1993Jan1.141633.1724@victrola.sea.wa.us> <1993Jan3.205523.23937@klaava.Helsinki.FI>
  8. Date: Sun, 3 Jan 1993 21:41:55 GMT
  9. Lines: 64
  10.  
  11. In article <1993Jan3.205523.23937@klaava.Helsinki.FI> kankkune@klaava.Helsinki.FI (Risto Kankkunen) writes:
  12. >>that's a feature, not a bug.
  13. >>many *nix'es don't allow that.
  14. >
  15. >OK, I can live with that, but is there any reason for this? I haven't
  16. >checked the sources (yet), but I think disallowing just requires extra
  17. >code with no benefits. Afterall, symlink is just a file containing the
  18. >path name of the file it points to.
  19.  
  20. There is no good way to handle this in the kernel: moving files (even
  21. symbolic links) across filesystems is pretty much impossible to do
  22. cleanly as different fs's can have different filesystem semantics, and
  23. the kernel proper (or rather, the vfs layer) doesn't know about them
  24. (nor does it care - the idea with the vfs is exactly to allow different
  25. filesystems to have different opinions of what is going on). 
  26.  
  27. It's very easy to fake this on a user level: either in the 'rename()'
  28. library call or just in the 'mv' binary.  The latter is probably the
  29. preferred way, if only because it serves for most people, while not
  30. cluttering up the library for other binaries (besides, handling the
  31. error cases might be ugly in the library, while 'mv' would know what to
  32. do). 
  33.  
  34. Naturally, any non-kernel solution (be it a library or mv change), is
  35. not guaranteed to be atomic, but with symbolic links this is probably
  36. not something you usually have to worry about.  And a move across
  37. filesystems would be hard to make atomic even in the kernel, even if it
  38. was something I though was worth it.  It's easy enough to fake with
  39. something like this:
  40.  
  41.     struct stat stat;
  42.  
  43.     if (lstat(oldname,&stat)) {
  44.         perror("lstat");
  45.         exit(1);
  46.     }
  47.     if (S_ISLINK(stat.st_mode)) {
  48.         char buffer[1024];
  49.  
  50.         if (readlink(oldname,buffer,sizeof(buffer)) < 0) {
  51.             perror("readlink");
  52.             exit(1);
  53.         }
  54.         if (symlink(buffer, newfile)) {
  55.             perror("symlink");
  56.             exit(1);
  57.         }
  58.         if (unlink(oldname)) {
  59.             perror("unlink");
  60.             exit(1);
  61.         }
  62.         return 0;
  63.     }
  64.  
  65. Note that GNU mv already does something similar with regular files (ie
  66. it copies them across filesystems and then unlinks the original file if
  67. the copy was successfull), but symbolic links aren't the only thing mv
  68. won't touch.  Directories, named pipes and any other special files share
  69. their non-movability with symlinks - understandable, as moving them can
  70. result in funny behavior (especially trying to move a directory by
  71. copying it and then removing it is so fraught with race-conditions that
  72. it's not really worth it). 
  73.  
  74.         Linus
  75.