[opensuse] diffs between symlinked dirs and mount-bind dirs (was Re: making swapfile on 3.2)
don fisher wrote:
Are there advantages to using rbind over the link? From your description is sounds as though they result in the same structure. If I have time to learn LVM I may try that option. I never considered partitions of any value, so I never employed them in the past.
I used the symlink type solution in the past as well. Problem is some software will see a symlink and think it is not a real 'dir', and simply overwrite it. For example, if you were to untar an image that wanted to write into the "symlinked" directory you created, 'tar', would likely, by default, overwrite the symlink rather than following it. There are multiple programs that get fussy with symlinks just like there are a growing number of ones that get fussy about what permissions you put on your files. But as a real life example of a an installer overwriting symlinks -- cygwin puts a linux/unix like layer overwindows, and in doing so, they made the windows' version of sub-dir-mounts (junctions made with linkd or mountvol), *look* like the symlinks you make with "mklink". As a result when you install SW, it just overwrites your local mount structure causing rather chaotic results. So if it looks like a symlink -- and you install software into the "virtual dir" that you get with the symlink, there is a fair chance it will remove your symlink and install itself on the underlying disk. 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). Oh, another difference, is that many recursive utilities won't follow symlinks by default (though many have options to do so). But you have to know which utils respect symlinks and which don't AND know which ones allow you to work around them. The *nix 'find' command has 3 top-level switches for changing symlink behavior (see 'man find' First line of the options descriptions talks about them).... Basically if what you have works for you, don't change it, but later on, it's good to know that some software may not work w/your choices and at least know what other options are available. BTW, if you respond to an email, don't feel you have to copy the whole email you are responding to into the new mail unless it is needed for context. I had to scroll through tons of my own writing till I got to yours... (*poor me!*) ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
participants (2)
-
Anton Aylward -
Linda Walsh