Re: patch for bonobo-storage-fs, dangling symlinks

[Vladimir Vukicevic <vladimir ximian com>]

On Mon, Apr 09, 2001 at 09:01:47AM +0200, Dietmar Maurer wrote:
> Vladimir Vukicevic wrote:
> > A related issue is that Bonobo/StorageInfo only knows about
> > STORAGE_TYPE_REGULAR and STORAGE_TYPE_DIRECTORY files.  It seems that
> > it should also have a STORAGE_TYPE_LINK (or _SYMLINK) -- right now,
> > the behaviour of the fs storage plugin is that it will give you info
> > about the file that's being pointed to, not the link itself.  Changing
> > this entails simply using lstat() in the first place instead of
> > stat(), but I wanted to get people's input if this makes sense...
> 
> I am unsure if we should do that, since the bonobo storage model does
> not know the concept of symlinks, i.e. it is also not possible to
> create a symlink or do something like lstat().  So I think this is
> nothing we should change now.

Ok, that's understandable -- what about just using lstat() and pretending
it's a regular file?  Doing it the way it's done now scares me -- let's say I
have a symlink from foo -> bar.  Bar is 100MB in size.  Right now, if
I were to do a getInfo() on "foo", I would get back that it's 100MB in
size.  If this information were presented to the user, and the user decides
to remove this file, he would expect 100MB to be freed -- but this won't
be the case, so there is a potential for confusion.  ("The file disappeared,
but the space is still used?!")

Ideally, I think StorageInfo would have a link_target element which is set
if the element is indeed a link with whatever the link points to... as far
as actually creating links within the storage interface, perhaps a 'link'
method similar to rename could be added.  I don't think that it's much
of an issue if there is no way to separately do lstat/stat -- if getInfo
always does lstat, if the programmer wants info about the symlink's target,
they can getInfo the link_target that they get back.  An issue would
be copyTo behaviour -- should it copy the symlinks or each symlink's data?  In
holding with the getInfo() argument above, I would say it should copy the
symlink -- if the symlink's data is to be copied, the link_target could
be copied. (This really only applies to Storage::copyTo..)

Anyway, if there's interest, I would be willing to make a patch to implement
some kind of support for links...

	- Vladimir