* Google Kreme <gkreme(_at_)gmail(_dot_)com> [2004-08-06 07:44]:
I thought the OS could not care less if there is a lockfile present,
and if a malicious or ill-configured process decides to write to a
file that already has a producer, the OS won't object. Isn't that
correct?
It's correct without a lock file.
I don't believe that, and I think what Reto said makes sense. Whether
or not there is a lock file makes no difference to the OS. Why should
OS care if there exists a lock file? How should the OS know what the
lockfile is named, or where it's located? I believe the only case
where an OS would object to a file write is when there is both a
kernal lock, and another process is writing to it.
Lockfiles only aid in procmail governing itself (correct me if I'm
wrong). Furthermore, this needlessly burdons the human developer with
having to micromanage what files get protection; when really the human
should simply be able to have an expectation that nothing gets
corrupted. The "system" (being procmail, the kernel, and the
filesystem) should be able to take care of that w/out human
intervention.
This is a shortcoming. It could be better. I'm not saying the
problem is in procmail - procmail is probably doing the best it can
given the platform.
Even if the OS knows about lockfiles and prevents it, it's silly
to open and write a new file solely for the purpose of setting a
flag, when the file at issue could contain a flag, which only
requires a file read.
So it makes more sense to intentionally munge the file?
I don't know where you get the idea that some kind of "munging" would
be required. Assuming by munging you mean to use something for which
it was not intended, I'm not saying that at all, and I would be
curious what it is you're thinking about. I'm saying there should be
a flag in the header of a file, stored in the metadata of the root
inode and transparent to whoever manipulates the payload of the file.
Only the filesystem and OS should have direct access to such a flag.
You're new to this whole *nix thing, aren't you?
Yes. I only have around 11 years of daily exposure to various *nix
platforms as an admin, developer, and end user, and still feel like I
don't even know half of it.
Someone mentioned OpenVMS.. but I'm not familiar w/ that OS. Is
it anything like VAX?
VMS is a OS, VAX is a machine that runs VMS.
I worked on one for a few months, and could not stand the shell. I
guess logging in from a Sun kept it abstract enough for me to not
differentiate between the OS and h/w. It's interesting to find that
this legacy OS is on the ball w/ file access, and linux is not.
Because the kernel lock has to tell the kernel on the OTHER END the
file is locked. That can be tricky. Or impossib
I have to disagree with that. The OS must protect its own resources
that it has custody over. It cannot be the job of a kernel to protect
remote resources that a governed by another OS. So the kernel lock
has to be enforced by the kernal that governs that system.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail