On 28 Jan, David Malone wrote:
> On Fri, Jan 27, 2006 at 02:01:19PM -0700, [EMAIL PROTECTED] wrote:
>> Sticking an fsync() in between the fchmod() and the close() causes the
>> bits to be cleared as a side-effect of the fsync(). Doing another
>> fchmod() after the fsync() produces the final expect
On Fri, Jan 27, 2006 at 02:01:19PM -0700, [EMAIL PROTECTED] wrote:
> Sticking an fsync() in between the fchmod() and the close() causes the
> bits to be cleared as a side-effect of the fsync(). Doing another
> fchmod() after the fsync() produces the final expected set{u,g}id
> results even after t
On Saturday 28 January 2006 07:31, [EMAIL PROTECTED] wrote:
> A demonstration program is included below. I've verified this on a
> fairly recently 5.4 client system, with both Linux and FBSD 5.4 NFS
> servers. I don't have 6 or -current available to me at the moment.
> There's the obvious work-ar
I've found an interesting little quirk that doesn't seem like it
should be working this way. If I:
fd = open(file)
write(fd, data)
fchmod(fd, 04711) /* or anything set{u,g}id */
close(fd)
The set{u,g}id bits get cleared by the close, but only if the amount
of dat
