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

[Ryan McDougall <ryan mcdougall telusplanet net>]

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

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

Cheers,
Ryan