On Saturday 26 February 2005 09:32, Russell Coker wrote:
It opens the file with O_CREAT (so if you were to do `echo -n
"" >
/tmp/flag` to create a flag file then it would work as expected), but never
calls the write(2) system call.
To unset the fscreate or exec context you have to call write(fd, X, 0) (the
value of X doesn't seem to matter as the kernel code doesn't dereference
it).
As a sidenote, dd behaves the same. dd if=/dev/null of=something does not call
write(2) because it doesn't need to write anything. Since no records were
read it assumes that no records must be written. Again, the output file would
be created because of the open("something", O_CREAT) call.
It seems likely to me that there may be other bits of kernel code
exporting
an interface under /proc where a write of 0 bytes may have a different
meaning to merely opening a file with write access and then closing it.
Then this is the problem, not bash, dd or whatever.
So it seems reasonable to me to consider this to be a bug in bash
where
it's optimisation of shell code results in the action requested by the user
not being performed correctly.
It's quite logical since if you do not have something to write, to not try to
write it.
It took a surprising amount of time for me to realise that bash
wasn't
doing what I expected of it and ran strace to prove it. I expect that most
sys-admins would take even longer to work it out (if they ever did).
This is indeed a problem, but the solution is not patching bash, dd, whatever.
I expect that the bash developers may disagree with this assessment
so I
would like some more input on the lists before I file a bug report.
If I were a bash developer I would disagree with you :) You would ask me to
make a workaround in bash to solve an issue that has its roots somewhere
else...
Mihai