The stat functions are extremely useful in getting file information, yet if
you want to write that information out you need to use a whole menagerie of
different functions. Eg: utime(), chmod(), chown(), chgrp() etc.

Anyone know the historic reasons for this? I'm writing a program which needs
to copy files and give the new files much of the same inode info as the old
ones and its very tedious having to use all the above functions instead of just
re-using the "struct stat" from the stat() call in one pass.

Muttley@dastardlyhq.com writes:
>The stat functions are extremely useful in getting file information, yet if
>you want to write that information out you need to use a whole menagerie of
>different functions. Eg: utime(), chmod(), chown(), chgrp() etc.
>
>Anyone know the historic reasons for this?

Basically, KISS.

Note that there were significant memory limitations in the
1970's - the more the kernel used, the less available for
applications.

And to be fair, it's far more common to need to change only one
attribute at a time.

On Tue, 14 Dec 2021 16:30:29 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>The stat functions are extremely useful in getting file information, yet if
>>you want to write that information out you need to use a whole menagerie of
>>different functions. Eg: utime(), chmod(), chown(), chgrp() etc.
>>
>>Anyone know the historic reasons for this?
>
>Basically, KISS.
>
>Note that there were significant memory limitations in the
>1970's - the more the kernel used, the less available for
>applications.
>
>And to be fair, it's far more common to need to change only one
>attribute at a time.

Not convinced by that reasoning as you could say the same for reading the
information (you usually only need a small part) yet *stat() was developed.

Muttley@dastardlyhq.com writes:
> On Tue, 14 Dec 2021 16:30:29 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>The stat functions are extremely useful in getting file information, yet if
>>>you want to write that information out you need to use a whole menagerie of
>>>different functions. Eg: utime(), chmod(), chown(), chgrp() etc.
>>>
>>>Anyone know the historic reasons for this?
>>
>>Basically, KISS.
>>
>>Note that there were significant memory limitations in the
>>1970's - the more the kernel used, the less available for
>>applications.
>>
>>And to be fair, it's far more common to need to change only one
>>attribute at a time.
>
> Not convinced by that reasoning as you could say the same for reading the
> information (you usually only need a small part) yet *stat() was developed.

Stat returns meta-information about files. It easy to and to use by
returning one structure containing all metainformation. But manipulating
all of this information is something different. This would require
something like a multiplexing call taking a bitmask of "change action"
flags and a structure. I'm unaware of the historical reason for this but
IMHO, that's an awful interface design.

On Tue, 14 Dec 2021 18:45:42 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Muttley@dastardlyhq.com writes:
>> On Tue, 14 Dec 2021 16:30:29 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>>Muttley@dastardlyhq.com writes:
>>>>The stat functions are extremely useful in getting file information, yet if
>>>>you want to write that information out you need to use a whole menagerie of
>>>>different functions. Eg: utime(), chmod(), chown(), chgrp() etc.
>>>>
>>>>Anyone know the historic reasons for this?
>>>
>>>Basically, KISS.
>>>
>>>Note that there were significant memory limitations in the
>>>1970's - the more the kernel used, the less available for
>>>applications.
>>>
>>>And to be fair, it's far more common to need to change only one
>>>attribute at a time.
>>
>> Not convinced by that reasoning as you could say the same for reading the
>> information (you usually only need a small part) yet *stat() was developed.
>
>Stat returns meta-information about files. It easy to and to use by
>returning one structure containing all metainformation. But manipulating
>all of this information is something different. This would require
>something like a multiplexing call taking a bitmask of "change action"
>flags and a structure. I'm unaware of the historical reason for this but
>IMHO, that's an awful interface design.

I guess we'll have to differ on that. I think it would be very useful in
certain situations, mainly with only having to do 1 system update and hence only
1 check instead of having to do multiple updates and multiple checks with
the file metadata potentially being left in a useless state if any one
of the updates fails (eg chmod() worked but chown() then fails) requiring some
kind of rollback. I'm not saying don't have the individual functions but
complement then with 1 call that updates everything.

On Tue, 14 Dec 2021 18:45:42 +0000, Rainer Weikusat wrote:

> Muttley@dastardlyhq.com writes:
>> On Tue, 14 Dec 2021 16:30:29 GMT scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>>Muttley@dastardlyhq.com writes:
>>>>The stat functions are extremely useful in getting file information,
>>>>yet if you want to write that information out you need to use a whole
>>>>menagerie of different functions. Eg: utime(), chmod(), chown(),
>>>>chgrp() etc.
>>>>
>>>>Anyone know the historic reasons for this?
>>>
>>>Basically, KISS.
>>>
>>>Note that there were significant memory limitations in the 1970's - the
>>>more the kernel used, the less available for applications.
>>>
>>>And to be fair, it's far more common to need to change only one
>>>attribute at a time.
>>
>> Not convinced by that reasoning as you could say the same for reading
>> the information (you usually only need a small part) yet *stat() was
>> developed.
>
> Stat returns meta-information about files.

Specifically, stat(2) returns a copy of (most of) the raw inode for the
specified file.

> It easy to and to use by
> returning one structure containing all metainformation.

Extremely easy, as all that metainformation sits together in the file's
inode, and the kernel can service the stat(2) call with a simple copy.

> But manipulating all of this information is something different. This
> would require something like a multiplexing call taking a bitmask of
> "change action" flags and a structure.

And, would directly edit a critical resource (the inode). The kernel
would have to sanity check such edits to ensure that the variety of
parameters provided do not conflict with each other, and do not violate
the integrity or security of the filesystem.

> I'm unaware of the historical
> reason for this but IMHO, that's an awful interface design.

If I understand the history correctly, stat(1) came first, as a simple
"dump" of the file inode data. After that, programmers found
"opportunities" to need to make arbitrary changes to the values in the
inode, outside of those syscalls that result in inode changes on their
own (creat(2),open(2), read(2), write(2), close(2), unlink(2), chown(2)
and chmod(2) ).

--
Lew Pitcher
"In Skills, We Trust"

Muttley@dastardlyhq.com writes:
> On Tue, 14 Dec 2021 18:45:42 +0000
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>Muttley@dastardlyhq.com writes:
>>> On Tue, 14 Dec 2021 16:30:29 GMT
>>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>Muttley@dastardlyhq.com writes:
>>>>>The stat functions are extremely useful in getting file information, yet if
>>>>>you want to write that information out you need to use a whole menagerie of
>>>>>different functions. Eg: utime(), chmod(), chown(), chgrp() etc.
>>>>>
>>>>>Anyone know the historic reasons for this?
>>>>
>>>>Basically, KISS.

[...]

>>> Not convinced by that reasoning as you could say the same for reading the
>>> information (you usually only need a small part) yet *stat() was developed.
>>
>>Stat returns meta-information about files. It easy to and to use by
>>returning one structure containing all metainformation. But manipulating
>>all of this information is something different. This would require
>>something like a multiplexing call taking a bitmask of "change action"
>>flags and a structure. I'm unaware of the historical reason for this but
>>IMHO, that's an awful interface design.
>
> I guess we'll have to differ on that. I think it would be very useful in
> certain situations, mainly with only having to do 1 system update and hence only
> 1 check instead of having to do multiple updates and multiple checks with
> the file metadata potentially being left in a useless state if any one
> of the updates fails (eg chmod() worked but chown() then fails) requiring some
> kind of rollback. I'm not saying don't have the individual functions but
> complement then with 1 call that updates everything.

This would only push the atomic update problem into the kernel. As a
further complication, the system call would probably need to support
update atomicity for any subset of the attributes or even any set of
non-overlapping subsets.

It's also not really difficult to make this appear atomically to other
applications: Start with creating a target file whith some unique,
internal name. Change all attributes supposed to be changed. If
everything succeeded, use link(2) to associate the existing file with the
'real' name it's supposed to have, finally, regardless of success or
failure of the preceding steps, unlink the internal name.

On Wed, 15 Dec 2021 17:17:33 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Muttley@dastardlyhq.com writes:
>> On Tue, 14 Dec 2021 18:45:42 +0000
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>Muttley@dastardlyhq.com writes:
>>>> On Tue, 14 Dec 2021 16:30:29 GMT
>>>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>>Muttley@dastardlyhq.com writes:
>>>>>>The stat functions are extremely useful in getting file information, yet
>if
>>>>>>you want to write that information out you need to use a whole menagerie
>of
>>>>>>different functions. Eg: utime(), chmod(), chown(), chgrp() etc.
>>>>>>
>>>>>>Anyone know the historic reasons for this?
>>>>>
>>>>>Basically, KISS.
>
>[...]
>
>>>> Not convinced by that reasoning as you could say the same for reading the
>>>> information (you usually only need a small part) yet *stat() was developed.
>
>>>
>>>Stat returns meta-information about files. It easy to and to use by
>>>returning one structure containing all metainformation. But manipulating
>>>all of this information is something different. This would require
>>>something like a multiplexing call taking a bitmask of "change action"
>>>flags and a structure. I'm unaware of the historical reason for this but
>>>IMHO, that's an awful interface design.
>>
>> I guess we'll have to differ on that. I think it would be very useful in
>> certain situations, mainly with only having to do 1 system update and hence
>only
>> 1 check instead of having to do multiple updates and multiple checks with
>> the file metadata potentially being left in a useless state if any one
>> of the updates fails (eg chmod() worked but chown() then fails) requiring
>some
>> kind of rollback. I'm not saying don't have the individual functions but
>> complement then with 1 call that updates everything.
>
>This would only push the atomic update problem into the kernel. As a

As as userspace dev thats exactly where I want it.

>further complication, the system call would probably need to support
>update atomicity for any subset of the attributes or even any set of
>non-overlapping subsets.
>
>It's also not really difficult to make this appear atomically to other
>applications: Start with creating a target file whith some unique,

Surely most (all) kernels have some kind of filesystem lock on inodes
preventing 2 or more processes updating them simultaniously otherwise you could
end up with serious corruption.

Muttley@dastardlyhq.com writes:
> On Wed, 15 Dec 2021 17:17:33 +0000
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>Muttley@dastardlyhq.com writes:
>>> On Tue, 14 Dec 2021 18:45:42 +0000
>>> Rainer Weikusat <rweikusat@talktalk.net> wrote:

[...]

>>> 1 check instead of having to do multiple updates and multiple checks with
>>> the file metadata potentially being left in a useless state if any one
>>> of the updates fails (eg chmod() worked but chown() then fails) requiring
>>some
>>> kind of rollback. I'm not saying don't have the individual functions but
>>> complement then with 1 call that updates everything.
>>
>>This would only push the atomic update problem into the kernel. As a
>>further complication, the system call would probably need to support
>>update atomicity for any subset of the attributes or even any set of
>>non-overlapping subsets.
>
> As as userspace dev thats exactly where I want it.

There's a sizable amount of policy decisions involve here, eg, what does
the application want to do? Eg, "Apply all changes and roll all applied
ones back if one of them can't be applied?" vs "Apply as many changes as
can be applied?"

I've encountered both in application code already.

Because of this, putting this in the kernel is IMO not a good idea.

>>It's also not really difficult to make this appear atomically to other
>>applications: Start with creating a target file whith some unique,
>>internal name. Change all attributes supposed to be changed. If
>>everything succeeded, use link(2) to associate the existing file with the
>>'real' name it's supposed to have, finally, regardless of success or
>>failure of the preceding steps, unlink the internal name.

> Surely most (all) kernels have some kind of filesystem lock on inodes
> preventing 2 or more processes updating them simultaniously otherwise you could
> end up with serious corruption.

Obviously. But the problem can be solved in an application and without
implementing rollback of individual changes, see algorithm described
above.