1

When the dir pointed by a symlink changes its name or ancestral dir(s), the symlink will not work. This happens often. Is there some more or less automatic way to make a symlink keep track of that?

I use symlinks to organize my directories. One topic is represented as a directory. A topic can have several subtopics, in the sense that a directory can have several subdirs. My topics are constantly under reorganization, so I often rename dirs, and change ancestral dirs.

Gilles 'SO- stop being evil'
  • 829,060
Tim
  • 101,790
  • No as the target doesn't know which symlinks point to it – Ulrich Dangel Aug 16 '14 at 14:25
  • What would do to maintain the sanity? – Tim Aug 16 '14 at 14:55
  • Stop symlinking directories and start --bind mounting them. You can maintain the entire tree in /etc/fstab. – mikeserv Aug 16 '14 at 16:18
  • @mikeserv Thank you. That seems to be a solution. Does mount --bind become not working if I change the mounted dir's ancestral dirs or its names? Is it different from hard links? How does it work? Feel free to post a reply. I always upvote replies. – Tim Aug 16 '14 at 17:19
  • 2
    it depends exactly what you need/want. It sounds like there is a bigger issue here at play, like about deployments, configuration management etc. Maybe write a small application which does what you want – Ulrich Dangel Aug 16 '14 at 18:56
  • @Ulrich: Organize my directories. one topic is represented as a directory. A topic can have several subtopics, in the sense that a directory can have several subdirs. My topics are constantly under reorganization, so i often rename dirs, and change ancestral dirs. – Tim Aug 16 '14 at 19:17
  • 1
    maybe have a look at http://tagstore.org/ anyway you should probably think about writing a software helping you manage your data. you could also look into knowledge management systems or document management systems… – Ulrich Dangel Aug 16 '14 at 20:03
  • @Tim - the kernel has a means of handling all sorts of different mounts - such as private (the regular kind), shared, bind, and slave. When deployed correctly, they can completely surmount any need for links of any kind. You can --bind mount a file over another file, for instance, and you can assign a mount to a namespace - like one process will see a mount tree in one way, while another will see it in another. These are fully filesystem independent. You'll want to do some googling if interested. Try echo hey >txt.file; sudo mount --bind /dev/null ./txt.file; cat ./txt.file – mikeserv Aug 16 '14 at 20:32
  • possible duplicate of Keep tracking of symbolic links? – Sparhawk Aug 16 '14 at 22:18
  • @mikeserv - Is your comment on the bind mounting not a worthwhile answer? The possible duplicate Sparhawk mentioned is a similar question, but the answer to that one doesn't mention bind mounting, therefore there's definitely value in keeping this one open. I've now had to Google shared and slave mounting :-) – garethTheRed Aug 17 '14 at 07:31
  • @garethTheRed - yes. I maybe could... but it is a pretty deep subject and I don't relish the idea. I might do anyway. In the meantime, if you get to playing with it, don't forget the unbindable mount type (as I did above) or you'll wind up with infinitely recursing mount trees. – mikeserv Aug 17 '14 at 21:59
  • @Tim - I guess I didn't answer that - no, a bind-mounted tree has nothing to do with file/dirnames at all. It is completely atomic and is rooted in the kernel's VFS - which is the filesystem upon which all linux filesystems must base themselves upon. So changing a a directory name or even moving it elsewhere either links through as expected for the bind/shared types, or is not propagated as expected for the private/slave mounts. There's an internal hierarchy that can be atomically affected via mounts in ways that can only be emulated otherwise - it's all kernel space. – mikeserv Aug 17 '14 at 22:06

0 Answers0