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.
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?
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.
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.
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.
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,
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 83:16:39 |
Calls: | 6,658 |
Calls today: | 4 |
Files: | 12,203 |
Messages: | 5,333,522 |
Posted today: | 1 |