On 03/09/2015 09:20 PM, Linda Walsh wrote:
In your case, it sound like you were just going to use it for user files and not installed apps, so you are probably safe, but if you install something into the symlinked location, the installer may get rid of the symlink for fear it is pointing somewhere it shouldn't (like your system directory) and since most people won't even notice the difference in a symlinked dir, it's too easy for 'crackers' to use the symlinks for bad things -- so the choice to follow them or not is often not left to the user (i.e. the owner of the system).
The 'Not left to the User" has a long and "honourable" history :-) All the way back to the 1980s when SUN and YP/NFS had what are not termed in some areas "roaming shares". You logged in at any workstation anywhere on the network and your /home (or equivalent) was there for you. Where do you think that M$ got the idea from? But it took YP/NIS to move the (equivalent of) /etc/passwd off individual machines so identification and authentication was "available anywhere". If my memory serves me correctly, the NFS mount was to known location and there were a pile of symbolic links from the /home (...) etc to that location. What you had was a very thin client, maybe even as thing as a the old PXE type of approach, or the kind of thin, thin types that we now see in the DRBL or the Linux Terminal Server Project. At one point SUN ran completely diskless nodes, even swap being done over the net! Oh boy, did that affect performance! What *is* left to the use is the content. In the example I gave there was the "/Development". No on my home system that is actually ~anton/Development, and its just me doing coding on this machine at home. But I've also set up shared development environments. My preference is to set up a central networked RCS of some kind, have the developer check out the part of the project they are working on and check in the results of their work. This is common and well established practice. Nothing odd here. But there are two exceptions. The first is the 'programming in the small' or the 'single person project'. Many lone developers/consultants, writers of many forms are the only person on the project. BTDT. Still use a RCS but still a one-person on one machine project. See above. The other is when the programmers want to share a workspace. So its pack to a NFS volume that they all can mount. Yes there are other complications that go with sharing NFS. But even if I have my /home/anton and/or parts below that NFS mounted, its not the problem Linda mentions, or needs not be. Under the "....../Development" which is is a symlink to, perhaps /mnt/NFSmounts/Server1/Development, there are subdirectories for each project. Focus on those. Backup and restore those, rather than "/Development". Its not idiot proof. But then some applications will burp on encountering NFS mounted directories, be they symlinked or not. Other will not cross mounts unless they are explicitly told to; other if told not to. No way are you going to keep every program happy with any approach. Perhaps its to avoid all this that the BtrFS people want just one big file system with no boundaries or mounts. The TAR example isn't as simple as it sounds. Unless you tell it, TAR might or might not traverse a symlink when creating the archive, depending on the version you are using. Then again, if you told it to traverse and store the files downstream of the symlink in the archive, if you were to unpack the archive on another machine in a 'virgin' folder, what would you expect it to do with those files? Stop and think about that problem for a moment and you'll see the hazard isn't as simple as Linda makes out. Then again, suppose you make a backup of a tree on a partition that is running out of space, delete the tree and create it over with symlinks to another partition or more than one partition in the manner I described for Don. Can you unpack the TAR archive and expect it to follow the symlinks by use of a command line option or will it always convert the symlinks to hard links as Linda suggests? What about using rsync? All these programs seem to have many command line options. They are not for "idiots". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org