[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: silent semantic changes in reiser4 (brief attempt to document the idea of what reiser4 wants to
From:       Spam <spam () tnonline ! net>
Date:       2004-08-31 22:15:57
Message-ID: 881572472.20040901001557 () tnonline ! net
[Download RAW message or body]


  

>>>>>> "Spam" == Spam  <spam@tnonline.net> writes:

V13>> The only thing that changes (from the userland POV) is the way
V13>> someone can enter the 'metadata directory'. This way you don't have
V13>> to have a special name, just a special function and no existing
V13>> application (like tar) can possibly break because it will not know
V13>> how to enter this 'metadata directory'.

>>> tar won't be able to backup the metadata.  That's the major breakage
>>> of tar that we're worried about.

Spam>>   However, if we do a "cp fileA fileB" then the metadata and
Spam>> streams ought to be copied too, even if "cp" does not support
Spam>> them.

> Huh?  How do you plan on pulling that off?  Unless cp uses the
> not-yet-existing copy syscall, if cp can't see the metadata or streams,
> how is it going to copy it?

  My first thought would change the API that cp uses to copy the file.
  But  in  an earlier response on this message thread I have found out
  that  there is no such API (well there is, but it is linked into the
  program)  and  cp  in fact itself is doing the copying. this is also
  what  I  objected  against  before. It is a bad design and should be
  attended  much  higher  interest to change than just adding adding a
  new type of file-as-dir.

Spam>> This is the real challenge. Backup tools like tar can be patched
Spam>> just like it has so many times before.

> Yes.  And if we can get file-as-dir, then we only need to patch tar
> once, since everything can be exported through that interface.

  Yes. This seem to be an acceptable way to do things. But next time
  someone comes and want to do changes like this we need to start
  patching things again. If there was an API that was separate from
  the programs then new features could be included much more easily as
  things could be done behind the scenes. ie the "cp fileA fileB"
  would succeed and all the extended attributes, metas, streams etc
  would be copied too. Nothing would ever be lost unless copying to a
  filesystem that doesn't support the special stuff. (as with NTFS
  file streams).

  ~S


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[prev in list] [next in list] [prev in thread] [next in thread]