Linux-kernel mailing list archive 2000-32,: Re: NTFS-like streams?

# Re: NTFS-like streams?

Theodore Y. Ts'o (tytso@MIT.EDU)
Sat, 12 Aug 2000 11:46:01 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jens Axboe: "Re: CDROM still does not work in 2.4.0-test6"
- Previous message: Guest section DW: "Re: [2.4.0-test6+] ioctl(FDFMTBEG): Operation not permitted"
- Maybe in reply to: Christopher Vickery: "NTFS-like streams?"
- Next in thread: Linus Torvalds: "Re: NTFS-like streams?"
- Reply: Linus Torvalds: "Re: NTFS-like streams?"

Date: Fri, 11 Aug 2000 20:36:30 -0700 (PDT)
From: dean gaudet <dgaudet-list-linux-kernel@arctic.org>

On 11 Aug 2000, Linus Torvalds wrote:

> fd = fd_open(fd, "Icon", O_RDWR | O_CREATE, 0666);
>
> which would essentially be the same as "open()", except it would start
> from "fd" instead of "cwd" like a regular open. There have been reasons
> to have something like this before (you can emulate it in a ugly manner
> by doing something like

yeah you want fd_open mostly in threaded programs i'd bet -- which your
example code wouldn't help with :)

also need fd_stat, fd_opendir, ...

This also brings up all sorts of *entertaining* security semantics
questions, which were never an issue on OS/2 and Macontish since they
didn't have user security.....

When are you allowed to create a fork inside a file to which you may not
own? Who gets charged the quota on forks that are created when you
don't own them?

If the answer is that "it works just like creating a file in a
directory", then after a point, what *is* the difference of having
"resource forks"? If we're just treating a "resource fork" as a
directory that also contains data, that's actually not that hard. In
fact, you could probably do it as a LD_PRELOAD, or as a libc hack. That
is:

1) Change "open(PATH)" to have the algorithm, "if the PATH is a
directory, try to open "PATH/__really_the_data_fork__" instead. If it
succeeds, return return the open fd to PATH/__really_the_data_fork__ as
the fd".

2) The call to create a resource, if the file hasn't already be "resource
forked", would translate to "mv PATH mktemp_PATH; mkdir PATH; mv
mktemp_PATH PATH/__really_the_data_fork__".

3) Attempts to open a resource would simply translate to PATH/RESOURCE

Is this what people really want? If not, what does your mental model
look like?

(One of the problems when arguing this point is that everyone has a
different model about what you might put in "named streams" or "extended
attributes". Some people think that a 32k limit on an extended
attribute is more than enough. Other people want you to be able to
store several megabytes of data there. And of course, whether extended
attributes should contain important data that will get lost when you ftp
the file ("FTP is broken; no one uses FTP!" -- Miguel de Icaza) is also
subject to change depending on which proponent of EA's you happen to be
talking to.....)

- Ted

-
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/

- Next message: Jens Axboe: "Re: CDROM still does not work in 2.4.0-test6"
- Previous message: Guest section DW: "Re: [2.4.0-test6+] ioctl(FDFMTBEG): Operation not permitted"
- Maybe in reply to: Christopher Vickery: "NTFS-like streams?"
- Next in thread: Linus Torvalds: "Re: NTFS-like streams?"
- Reply: Linus Torvalds: "Re: NTFS-like streams?"