[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Subfile GSoC (Re: Implementation Proposal for ...)
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
: 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
: 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.
Main Index |
Thread Index |