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". 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.
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.
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.
Or, my favorite from mainframe days, the ability to do something like
crypt my_key <datafile >datafile
and have it either finish with the new data file there or bomb out with
the old data file intact.
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.
}
waitpid(child_pid, NULL, 0);
And if you make a mistake here, ... the file is left behind?
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?
}
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. :-)
Interestingly, Windows programs still do the same thing.
Not all of them. Obviously it's not supported on the legacy file
systems, so some programs that are supposed to work with FAT and/or were
ported from Linux do something different.
Sadly, this represents the vast majority of Windows software. I've
learned this the hard way. :-(
Yeah. Backwards compatibility is a bitch.
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
