Re: Subfile GSoC (Re: Implementation Proposal for ...)

[Dieter Baron <dillo%KD119105101110.ppp-bb.dion.ne.jp@localhost>]

In article <Pine.NEB.4.64.0805252211050.27336@simak> Magnus wrote:

: Just thinking out loud on a couple of points.


: On Sun, 25 May 2008, Jan Danielsson wrote:
: > So don't make the mistake of implementing some fall-back method for
: > generic-filesystem-compatibility, unless you've _really_ thought it
: > through.

: Would a /path/to/file/rsrc -like scheme work in this case?  "Everything is
: a file", etc.  Copy to FAT partition (e.g. USB key) with an aware tool,
: end up with separate files.  Copy back, and the complete file is
: reconstructed.

: A non-aware tool would see two files, it would mean you get e.g. tar files
: that are at least valid on other systems, and includes all of the
: necessary information for reconstructing the original files.
  You would have to make /path/to/file a directory and move the main
datastream into it, which has two main problems:

- non-aware tools won't find the main data stream where they expect
  them, probably even with a different extensions, which, especially for
  Windows, might cause problems.

- there is now an ambiguity of wether /path/to/file is meant to be a
  file with subfiles or a real directory with unfortunately named files
  in it.

: You could still end up with separate subfiles and ... ah, forget it.  End
: up with separate *data and resource forks*, in separate normal files, but
: they would be located together, in a predictable way, and could possibly
: be reintegrated.

  For MacOS data/resource forks, there are at least three common
schemes to achive that.  All of them have problems with ambiguity and
non-aware tools trashing consistency.  Some of them also have the
problem of not placing the data fork (main data stream) where
non-aware tools would expect it.

                                        yours,
                                        dillo