# >So when /bin/cp accesses the file it will get all streams
# >and when /usr/bin/xv accesses the file it will only get the
# >"main image" it wants?
#
# Can't be done.
#
# "/bin/mv", yes. Makes complete sense to move a full file with all
# "subforks". It's actually very similar to a directory move.
#
# But /bin/cp cannot do the same, at least not without teaching it to do
# the same thing as for a recursive directory copy (which a regular UNIX
# cp wouldn't even try to do on a regular file). But the recursive
# directory copy approach should work.
If the support was in the kernel for it, and subsequently a runtime
library (libfork?), adding conditional code to fileutils would be fairly
trivial, I would've thought. An autoconf test for the presence of fork
support would be pretty easy to do.
For the most part, programs would never deal with forks - I think the only
exception would be cp (or anything else that copies whole files) - unless
you specifically wanted them to. Having the normal API ignore forks, and
provide an extra API for specifically accessing them would work well,
IMHO. So long as people don't start using forks for storing vital
information in forks of files that could well be manipulated by things
that are likely to clobber them (which I believe someone mentioned was the
problem with the Mac implementation).
IIRC, NT gets around a lot of this by having an API call for copying files
(CopyFile(), I believe), which handles this automagically, although I
don't really see the point. If people started using forks, they'd have to
live with the fact that most programs won't know about them, and
there's a risk that those programs could clobber the forks. Caveat user,
in that situation - MS faced the same problem when implementing VFAT (if
a version of DOS that didn't support LFNs copied the file, the LFN would
be lost - same applies here, I think).
Hmm, perhaps I shouldn't talk about Microsoft's implementation strategies
on the LKML *grin*
-- Mo McKinlay Chief Software Architect inter/open Labs ------------------------------------------------------------------------- GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:26 EST