Darren New wrote:
> Christopher Smith wrote:
>> There are lots of useless features implemented in filesystems and other
>> technology components.
>
> Yes. But whether a particular bit is "useless" is up to the user, not
> the implementer. Obviously, Apple didn't think resource forks were
> "useless", and Microsoft doesn't think streams are "useless".
They didn't *think* they were useless, but in practice, over time,
resource forks are used less and less at Apple, and Microsoft keeps
finding new ways to introduce security leaks using them. ;-)
> Note that streams are used invisibly all over the file system, such as for
> encrypted file key management, the MS equivalent of Apple's "Get Info",
> and so on.
Yes, they have found some uses for them, but for the most part it feels
like a solution looking for a problem. I know for some problems it is
the ideal solu
>> Frankly, I'm with Hans Reiser on this issue: you already
>> have a perfectly good namespace, why introduce another orthogonal one.
>
> You could say that about users vs groups, and heirarchical directories
> vs flat directory structures, and databases vs tables.
Well, you could ask the question, but the difference is in those other
cases you'd have a better answer. ;-)
>> Yeah, I was not seeing the value of having the name exposed, so the
>> solution I was proposing was exactly what you are describing.
>
> Stuff like the C compiler outputting assembler, the assembler reading it
> and outputting object code, which the linker reads and links, leaving
> you only with the executable, with all the intermediate files deleted if
> the top-level process crashes out.
Ah, see on Unix you just use pipes to do that. Problem solved.
Alternatively the "open, delete, and close later" trick would also work
for that.
>> int fd = openat(dir_fd, path, O_CREAT | 0_RDWR);
>> if (pid_t child_pid = fork()) {
>> if (-1 == child_pid) {
>> std::cerr << "Error[" << errno << "] spawning child"
>> << std::endl;
>> abort();
>
> And this... leaves the file behind? Not sure of your point.
See, I told you I produce bugs all the time. ;-)
My bad, the openat() should really be done by the child process.
>> }
>> waitpid(child_pid, NULL, 0);
>
> And if you make a mistake here, ... the file is left behind?
I'm not sure I understand the kind of mistake you are referring to, but yes.
>> if (0 != unlinkat(dir_fd, path, 0)) {
>> std::cerr << "Error[" << errno << "] removing file "
>> << path << std::endl;
>> abort();
>
> And if it for some reason doesn't unlink (say, someone change directory
> permissions while you were running the child) then your data is left
> behind?
Yes.
>> }
>> exit(0);
>> } else {
>> /* do whatever */
>> }
>>
>> But that is a heck of a lot more work and ugliness for what Windows
>> gives you practically for free.
>
> No, as I said, I don't think Windows does this either. This is a thing I
> miss from my mainframe days. :-)
I believe by directly accessing the facilities in NTFS you can actually
do this magic. The Win32 API doesn't really expose it, but I think if
you use MTS it does happen.
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
