Messages in this thread | | | Date | Sat, 12 Aug 2000 01:02:53 -0700 (PDT) | From | Alex Belits <> | Subject | Re: NTFS-like streams? |
| |
On Sat, 12 Aug 2000, Mo McKinlay wrote:
> cat file1 file2 > file3 > > Net result, file3 contains: > > file1 > file1's forks > file2 > file2's forks > > In that order.
It can be just declared to be valid -- that additional forks can be placed anywhere in the file after the first segment.
> And you'd have to handle the cases where you seek to the end of the file > and append data to it...you'd have continually move the forks out of the > way - which would give you a nasty speed penalty.
This is why to deal with that kind of data it should be opened as forks only -- this can't be made backward-compatible.
> > Breaking backward compatibility is *bad*. In this case, it's much better > to have a specific API for dealing with the streams, and work on the > assumption that a stream may get clobbered, than break backwards > compatibility for the sake of something which wouldn't get used all that > much for a fair while (even if other operating systems did implement it, > it'd still be a while before it caught on proper).
Probably this is what it will end up with -- that files that contain forks will have very limited backward compatibility (if read directly they start from what is supposed to be the first fork/stream, and by reading the whole file one can precisely find where the first fork ends), and everything else is guaranteed to work only if all files that contain forks opened separately for all forks. I assumed that the goal to preserve all forks in often used trivial operations that are now nondestructive or round-trip-safe (copying, cinpressing/uncompressing, archiving, accessing over NFS, transferring files over ftp/http/...) is primary, and allowing various kinds of messing with file content is less important.
-- Alex
---------------------------------------------------------------------- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward
- 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/
| |