Re: What about these (old/annoying) bugs ?

[Olaf Frączyk <olaf cbk poznan pl>]

On Tue, 2003-12-16 at 06:41, Ryan McDougall wrote:
> On Mon, 2003-12-15 at 02:14, Olaf Frączyk wrote:
> > On Mon, 2003-12-15 at 03:44, Ryan McDougall wrote:
> > > On Fri, 2003-12-12 at 05:45, Julien Olivier wrote:
> > > > > Next question: Given the unix unified filesystem tree. How do you know
> > > > > if a filesystem is remote or removable?
> > > > 
> > > > Maybe - in a near future - using HAL ?
> > > > 
> > > > -- 
> > > > Julien Olivier <julo altern org>
> > > 
> > > I have to say that this has a correct ring to it, our systems should
> > > always know about itself, even if that information is purposefully hid
> > > from the user. 
> > > 
> > > A sophisticated solution is to always use a FS layer which would
> > > automatically implement "move" commands on remote FSs as a "copy"
> > > command.
> > And what if you really wanted to move an item? It will be not possible.
> > It's not sophisticated - it's the worst thing that could be done.
> > 
> > Regards,
> > 
> > Olaf
> > 
> 
> I guess from jumping in the thread late Ive missed some things, and
> writing emails late Ive not made anything clear, so let me try again:
> Not all devices are the same, but we rightfully attempt to make them
> appear the same, for ease of use reasons, by abstracting them out as
> file systems. All I am saying is now that we have much more computing
> resources available on any given system we should be spending cycles to
> make the layers more aware of their context and providing more
> sophisticated solutions without being asked explicitly. For example, If
> I ask to move a file from a read-only file system it shouldn't error out
> for largely pedantic reasons, it should just copy the data. If
This may be true for filemanager. For many other applications it's not.
There are many cases in which the application needs to know that "move"
failed and a "copy" was performed. So, it can't be done transparently in
VFS. 
The only way would be to make an additional layer on top of VFS. Such
layer would then be used by filemanagers. I don't think it's a good
idea. 
> connecting to an unreliable remote FS, then yes the default should be to
> copy the data, not move it -- however in a layer it would be up to the
> system designer to decide what is most appropriate for that specific
> kind of device. ( A move is nothing more than copy followed by a delete,
> so any system where you can copy and delete, a "move" is always
> possible. )
This is true for read-only filesystem. But for remote one, you need to
be able to do both "copy" and "move", what is the default, is a
different thing. 
> Ok so "move" as "copy" doesnt work under all situations, my only point
> was that this sort of semantics shouldnt be hard coded into applications
> that use the FSs, they should be dynamic in the FS itself.
> I hope I have clarified things a little, and you no longer think my
> ideas are "the worst thing that could be done".
I'm sorry if you feel resentful. I didn't intent to be impolite.

Regards,

Olaf