Fwd: Re: [Clipart] metadata: aren't the keywords actually categories (and can keywords be added)?

[Glen Turner]

Mike Traum wrote:
> Jonadab,
> The big xml file could also be exploded by any tool that could read
> xml, but that's moot because I misunderstood the implications of a
> hard link.
> 
> Further along in this thread you'll see that I was totally mistaken
> about how a hard link was represented on ext2, ext3, and probably
> most other unix based filesystems (ie, it's just an inode reference,
> and not a copy of the file). This also works in tar.
> 
> So, I think that using hardlinks is quite an appropriate solution,
> assumming that the release manager is builing the packages on a
> unix/linux system which supports them. You get the benefit of having
> a smaller download and users who are using firesystems which support
> them get the benefit of saving storage space. The only issue is users
> who are using filesystems which don't support them (Windows, FAT32
> and NTFS i believe) will end up using more of their local store, but
> that seems acceptable to me.

Hi,

Firstly, my apologies for not having read the previous postings
in this thread, but this e-mail caught my attention.

Hard links are seen as evil by system administrators and I would
strongly encourage you not to use them.

They don't cross filesystems (since they are an inode reference)
so sysadmins are constrained as to the partitioning of the system's
disks (and this factor alone has seen them disappear from modern
Unix systems).

Also, consider finding the hardlink reference.  ls -l suffices
to determine where a symlink goes. For a hardlink you need
"ls -i -R | sort -n" for the filesystem.  Sysadmins hate that
sort of crap.

Hard links also allow two sets of file ownsership and permission.
That really sucks if you are trying to find out who can alter a
file, as you need to find all the hardlinks to the file.  It
complicates the semantics of mv no end.

Because of the difficulty of finding which file references a
hardlink many backup utilities simply make two copies of hard
linked files [1] so the idea that hardlinks save space is a tad
bogus.  Tar is a good example -- its handling of symlinks is
straightforward, whereas its handling of hardlinks is full of
gotchas.

The "best practice" way of doing a link is a "relative symlink"
For example, take the directories
     a/b/c.txt
     d/e/
if you want a file g.txt to link to a.txt do this
     cd d/e
     ln -s ../../a/b/c.txt g.txt

The relative symlink allows the link to continue to work if
the partition is mounted in an unexpected place (not uncommon
during recovery from system errors).

You'll find hard links are used so rarely now that some packaging
formats don't support them (for example, Debian policy on dpkg
source files).  So they're not really portable any more.

Cheers,
Glen

  [1] To correctly handle hardlinks the backup utility needs
      to have handy a list of the the partition and inode of
      every file it has backed up.  It can then check the
      partition+inode of the file it is about to back up against
      that list. If this sounds simple, consider the incremental
      backup case and the parallel tape backup case.

-- 
  Glen Turner         Tel: (08) 8303 3936 or +61 8 8303 3936
  Australia's Academic & Research Network  www.aarnet.edu.au