Fwd: Re: [Clipart] metadata: aren't the keywords actually categories (and can keywords be added)?
mtraum at yahoo.com
Mon Apr 18 07:00:28 PDT 2005
This is all very good to know. Thanks for the input.
The problem with symlinks is that they, AFAIK, are not at all
compatible with non-unix/linux filesystems.
So, what's the answer here? I really think making copies of the files
is a bad way to go, for three reasons:
1. Slower downloads for the user
2. More bandwidth being used on the server (which isn't cheap)
3. More starage space used on all clients filesystems
The perfect answer, to me, was hardlinks. But, in light of Glen's
statements, I have no good solution, while still being able to retain
the ease and friendliness of having a category-based file path
distribution bundle. Anyone else?
--- Glen Turner <glen.turner at aarnet.edu.au> wrote:
> Mike Traum wrote:
> > Jonadab,
> > The big xml file could also be exploded by any tool that could
> > xml, but that's moot because I misunderstood the implications of
> > hard link.
> > Further along in this thread you'll see that I was totally
> > about how a hard link was represented on ext2, ext3, and probably
> > most other unix based filesystems (ie, it's just an inode
> > and not a copy of the file). This also works in tar.
> > So, I think that using hardlinks is quite an appropriate
> > assumming that the release manager is builing the packages on a
> > unix/linux system which supports them. You get the benefit of
> > a smaller download and users who are using firesystems which
> > them get the benefit of saving storage space. The only issue is
> > who are using filesystems which don't support them (Windows,
> > and NTFS i believe) will end up using more of their local store,
> > that seems acceptable to me.
> 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  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
> The "best practice" way of doing a link is a "relative symlink"
> For example, take the directories
> 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.
>  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
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
More information about the clipart