Create old style ‘slow’ symbolic links

Concering your second question, if you make the symlink using a relative path and then move the whole directory structure, it still should work. Consider the following terminal session:

~$ mkdir test
~$ cd test/
~/test$ mkdir test2
~/test$ cd test2/
~/test/test2$ touch testfile; echo "hello, world" > testfile
~/test/test2$ cat testfile 
hello, world
~/test/test2$ cd ..
~/test$ ln -s ./test2/testfile testfileln
~/test$ ls -l
total 8
drwxr-xr-x 2 xxxx xxxx 4096 2010-09-09 09:18 test2
lrwxrwxrwx 1 xxxx xxxx   16 2010-09-09 09:18 testfileln -> ./test2/testfile
~/test$ cd ..
~$ mv test/ testfoo
~$ cd testfoo/
~/testfoo$ ls -l
total 8
drwxr-xr-x 2 xxxx xxxx 4096 2010-09-09 09:18 test2
lrwxrwxrwx 1 xxxx xxxx   16 2010-09-09 09:18 testfileln -> ./test2/testfile
/testfoo$ cat testfileln 
hello, world

As for your first question, if you really want a link that will refer to the same file no matter what you do with the original location of the file, a hard link is probably what you want. A hard link is basically just another name refering to the same inode. Thus, there is no difference between the hard link and the "original file." However, if you need to link across file systems, hard links often do not work and you usually cannot make hard links to directories. Further, you will notice some differences when performing some file operations. Most notably, removing the original will not remove the file. The hard link will still point to the file and be accessible.

Symbolic links do take room, of course, but just the room it takes to store the name and target plus a few bytes for other metadata. The space taken by a symbolic link does not depend on the space taken by the target (after all, the target is not even required to exist).

Plain du reports the space taken by a directory tree on the disk. du -L reports the space that would be taken by a directory tree if all symbolic links were replaced by their target. The former is usually the useful information; for example, it's the space you'd recover if you deleted the tree, and it's (approximately) the space you need to back up the tree.

du on a directory tree shows (usually) a little more than the total of the file sizes. That's due to two things. First, du also counts directories, which take a little room to store file names and metadata. Second, du counts the disk space taken by a file, which can be different from the file size: the most common effect is that files take up an integer number of blocks (4kB on a typical Linux installation), so a 1-byte file can show as 4kB in du output; but compression (such as the primitive form provided by sparse files on just about every unix filesystem) can make the file size larger than its disk usage.

From the numbers you give, it appears that Thunar reports the sum of the sizes of the files in the directory tree, following symbolic links. It's actually saying so in a subtle way — it's claiming that the total size is 570.3 kB, not that the disk usage is 570.3 kB. What is not at all apparent from the user interface or documentation is that Thunar follows symbolic links when computing the size.

Which one is “right” is a subjective matter. du reports disk usage. Thunar reports total size following symbolic links. Creating a symbolic link has a negligible impact on disk usage, but by definition does change total-size-following-symbolic-links that Thunar reports.