>> NTFS has a 4th time stamp.
>
> Fsck, no. Not another OOB channel for whatever random bullshit
> somebody wants to push through. Not another ioctl() - we have
> enough mess already.
We could really use something that:
* comes in all the variants (FOO, lFOO, and fFOO)
* handles misc. junk like ioctl does()
* is tidy, unlike ioctl() -- size ought to be a parameter
>> HFS has type and creator data.
>
> No. Way. In. Hell. It's *not* a support for forks - if you want
Those are simple 32-bit values.
> Mac'n'dreck you know where to find it. Again, it's a *narrow* channel -
> here I completely agree with Linus. The goal being to reduce the bloody
> clutter, not to introduce one more dungheap a-la ioctl().
So developers are stuck with ioctl() + a new API.
They have to learn something new, but can't junk the cruft.
>> Oh, be sure to use a 64-bit inode if you return that data.
>
> I don't see any place for inumber there.
You started with "new_stat" for a name.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/