We may want a program which unfortunately has a path to a shortcut to still work if the files they point to are moved. On Oct 9, 2014 7:56 PM, "Pascal J. Bourguignon" <p...@informatimago.com> wrote:
> Daniel W Gelder <daniel.w.gel...@gmail.com> writes: > > > The original question seems to be how to maintain links when the file > > is moved or renamed. Perhaps the file could have a unique ID in the > > file system, and the link would try the given pathname, but if it's > > not there, try the unique ID. Would that work? > > That's about what is done by MacOS and MacOSX (at least on HFS, I don't > know if they do the same on UFS). > > This let aliases to keep working when you move the target files. So > aliases, which in a way are more like symbol links (if you delete the > target file and recreate it in the same path, then the alias will refer > the new file), actually behave more like symbolic links in that you can > move the target file, and the alias will still refer it. > > Now the question, is what happens if you move away the original target, > and recreat a new one in the old path? > > As a MacOS and then MacOSX user, I DO NOT KNOW! > > I would have to try it. > > The point is that the semantics of symbolic links and of hard links are > clear and easy to understand, and manipulate. > > The semantics of MacOS and MacOSX aliases are not. > > And I don't know anything about links in MS-Windows (I'd expect they'd > work as broken Mac aliases). > > > There's some level of DWIM in that. > > > The question should be whether we want a system that DWIM, or whether we > want a system that implement simple and composable operations that can > easily be understood and used? > > > -- > __Pascal Bourguignon__ http://www.informatimago.com/ > “The factory of the future will have only two employees, a man and a > dog. The man will be there to feed the dog. The dog will be there to > keep the man from touching the equipment.” -- Carl Bass CEO Autodesk > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
