shortcut to storage-folder

[mprs]

is it possible to make a shortcut in /home/xyz/download to the storage-folder? and how?

[DanielM]

You mean something like

Code: Select all

ln -s /home/xyz/download /home/storage/download

?

/Daniel

[Gordon]

You should probably reserve the use of `ln -s` for regular files only. When linking to a folder it is better to create a mountpoint towards it:

Code: Select all

mount --bind /home/storage/somefolder /home/xyz/download/somefolder

[mprs]

YES! It worked... - Thank you Gordon

[Gordon]

You're very welcome.

One thing: a mount will not re-establish itself if you reboot. You should add the mount command to a boot-time script if you want this to be persistent.

Alternatively you could add an entry for it in /etc/fstab:

Code: Select all

/home/storage/somefolder   /home/xyz/download/somefolder   none   rw,bind   0  0

[DanielM]

You should probably reserve the use of `ln -s` for regular files only. When linking to a folder it is better to create a mountpoint towards it:

Why is that?

/Daniel

[Gordon]

You should probably reserve the use of `ln -s` for regular files only. When linking to a folder it is better to create a mountpoint towards it:

Why is that?

/Daniel

I've read an article about it once in a magazine. Essentially what it comes down to is if you symlink a folder it will require an additional read (of the symlink/inode) each time you want to access a file within that folder. With heavy I/O this could create a huge amount of latency and I would suspect the ARM processor won't make this any better.

A mount on the other hand will offer a direct gateway to the data and eliminate the need for the additional read. It also offers more flexibility when using services that offer remote file access, e.g. smb, http, ftp; some of these services may in fact downright refuse to traverse a symlink.

The only real issue with `mount --bind` that I can think of is that you can't really detect that the same substructure is referenced more than once. This can result in some unexpected behaviour, such as when searching the file system for a specifically named file (`find -name`); if you have the same 1TB referenced say ten times, you'll be in for a long wait before that finishes

[DanielM]

I've read an article about it once in a magazine. Essentially what it comes down to is if you symlink a folder it will require an additional read (of the symlink/inode) each time you want to access a file within that folder. With heavy I/O this could create a huge amount of latency and I would suspect the ARM processor won't make this any better.

A mount on the other hand will offer a direct gateway to the data and eliminate the need for the additional read. It also offers more flexibility when using services that offer remote file access, e.g. smb, http, ftp; some of these services may in fact downright refuse to traverse a symlink.

The only real issue with `mount --bind` that I can think of is that you can't really detect that the same substructure is referenced more than once. This can result in some unexpected behaviour, such as when searching the file system for a specifically named file (`find -name`); if you have the same 1TB referenced say ten times, you'll be in for a long wait before that finishes

Ok. Thanks for the info. Good to know when to use what, I'm most used to symlinks.

/Daniel

[Ubi]

but you cannot create mountpoints in userland, so you need rood privs each and every time. BUT, if you put the mountpoint within the user homedir, AND put the mount command in /etc/fstab, AND the user removes the mount point, you will see a boot failure (as you cannot protect against user deleting the mount point except for one really dubious trick.) This is because mount will fail (the mount position is absent) and the boot sequence will give you a shell to fix (which there is none). Again, there is a trick around it (by making the mount non-essential) but my point really is that the mount alternative has some caveats.

Is this understandable?

[DanielM]

Is this understandable?

Yep. Thanks for another good explanation!

/Daniel

[Gordon]

True, you need to be root to be able to mount stuff. I'm thinking however that you're regarding this as some on-off solution, which would not be the case. The folder would be mounted at boottime and only released during shutdown. I do not think a user, or even root, could be able to delete an active mountpoint.

As stated before, you can do a lot with rc.local. Call any script or run in-line code. You could check for a mountpoint to exist and create if it doesn't prior to actually calling the mount command. You could build a loop around it so you can do this for every user, even the ones that didn't exist before. There's one potential danger in this case however: if the objective is to map the download folder itself onto storage then filetransferdaemon, which is started earlier in the boot sequence, might already have active open files in the original location. As long as the file stays opened ftd will be able to write to it and complete it, but the user will never see that completed file.

[Ubi]

you are correct! Such a script would make it save. And indeed, if you make sure the mount is established before the user can access the folder, it can no longer be destroyed.

But after discussing all these pitfalls, wouldn't you simply check if making a symlink really does result in a notable performance problem before starting such an elaborate alternative?

[Gordon]

you are correct! Such a script would make it save. And indeed, if you make sure the mount is established before the user can access the folder, it can no longer be destroyed.

But after discussing all these pitfalls, wouldn't you simply check if making a symlink really does result in a notable performance problem before starting such an elaborate alternative?

Elaborate or uncommon? We have a saying here that roughly translates as "if everybody jumps into a brook, will that prompt you to do it as well?" Thing is that even if misbehaviour is common, that still doesn't make it good practice.

Here's a sample of a piece of code I use myself on an ftp server. This particular server runs vsftpd, which does not support traversing symlinks. It won't do it: period.

Code: Select all

#!/bin/sh

#  what folders to use
public="/mnt/md1/ftp"
homes="/home"

# some fancy formatting for my feedback messages
indent="\040\040\040\040\040\040"

# prepare the command to execute (and message to show)
# '\$' will just print '$' - the purpose is to evaluate $<varname> later, not now. 
if [ "$1" == "on" ]; then
  command="mount --bind \${public}/\${dirname} \${homes}/\${account}/\${dirname}"
  msg1="echo -e \"\${indent}Binding folders for user \${account}\n\${indent}\c\""

elif [ "$1" == "off" ]; then
  command="umount \${homes}/\${account}/\${dirname}"
  msg1="echo -e \"\${indent}Unbinding folders for user \${account}\n\${indent}\c\""

else
  echo "Usage: `basename $0` on/off"
  exit $E_BADARGS
fi

# A Bash representation of an Implode() function:
# creates a colon separated list of entries in the $public (the root ftp!) folder 
delim=""
dirnames=`ls -1 ${public} | while read dirname; do
  echo -e "${delim}${dirname}\c"
  if [ -z ${delim} ]; then
    delim=:
  fi
done`

saveifs=$IFS
ls -1 ${homes} | while read account; do   # for each entry in $homes
  if [ -d ${homes}/${account} ]; then
    eval ${msg1}    # print what I'm doing
    IFS=:
    for dirname in ${dirnames}; do   # for each of the entries in $public 
      if [ -d ${homes}/${account}/${dirname} ]; then   # if I have a matching entry in a home directory
        echo -e "  ${dirname}\c"
        eval ${command}    # run the prepared command
      fi
    done
    IFS=${saveifs}
    echo
  fi
done

So what this does is create a mapping (when called with 'on') from a folder in the user's home directory to a corresponding directory in the (anonymous) ftp root directory. This allows me to let authenticated users see the public folders and their own files and folders in their own chrooted environment.

Note that there's probably no sense for anyone else to implement this script as is. Just look at it as an example of how it could be done. Improve it...

[Ubi]

Gordon, you keep on pushing these really nice scripts and I don't want to specifically take the piss out of your effort, but I would like to stick to the KISS principle. No matter how elegant the script, a simple symlink is easier. If the symlink alternative poses no performance hit, what is the benefit of the mount?

[Gordon]

Gordon, you keep on pushing these really nice scripts and I don't want to specifically take the piss out of your effort, but I would like to stick to the KISS principle. No matter how elegant the script, a simple symlink is easier. If the symlink alternative poses no performance hit, what is the benefit of the mount?

There's no effort involved; I've been using most of these scripts for years. I also have scripts written in perl where more advanced stuff is required.

To answer your question, and I already stated this before, symlinks don't always work with the software you're using. So to reverse the question: can you, or can you not, confirm that ftd will function correctly if the Downloads folder is a symlink towards another location, e.g. in storage?

Also, according to my check the Samba server in the B3 is not configured to explicitly allow traversing symlinks. I'm actually amazed that it still appears to accept following symlinks, since it has become my understanding that the Samba crew had changed the default to not follow symlinks early 2010. Will that new default be applied with the upcoming update and cause the symlinks to suddenly be inaccessible? i.e. I'm assuming Excito won't just overwrite any config files that may have been changed by owners - I hope?

Using symlinks can also lead to unexpected behaviour with applications that have no knowledge about the fact that they are in reality accessing a different file. This probably does not apply to symlinked folders, but I know from experience that if you make changes to a file on a Samba share and the file is actually a symlink you may find that the symlink has become a regular file and the file you thought you were updating has remained unchanged.

YOMV but I think it's unwise to grant non-native access to symlinked objects and then allow write access to them as well. Symlinks will be fine as long as you stick to the native file system; they're quick and dirty (and I like quick and dirty) and they're persistent once created. Symlinks are also limited in their functionality and you should know what you're doing when you cross that limit; this can not be expected from a user that is running MS Windows and relies on Samba to do the right thing, because it won't.