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

[Dietmar Maurer <dietmar ximian com>]

Vladimir Vukicevic wrote:

> 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?!")

I would say this is confusing, but it is also a very seldom situation. And I
think
we have to use stat() for directory links.

> 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...

The question is: Should we extend the Storage interface to be flexible enough
to handle all POSIX file system functions (something like gnome-vfs), or is it
only used to store compound document data?

- Dietmar