I have a Bash script that renames files after being listened to:

FILE=$(ls -tr|head -n 1) # get the oldest file
aplay $FILE # where $FILE is a wav file
mv $FILE $(date +"%Y%m%d_%H%M").wav

However the resulting file doesn't get its timestamp changed, so I have to:

FILE=$(ls -tr|head -n 1
aplay $FILE
touch $FILE
mv $FILE $(date +"%Y%m%d_%H%M").wav


which is fine, but I wonder if there is a way for "mv" to update the
timestamp without using "touch".

Thanks.

--
Ottavio Caruso

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20.07.2023 11:01, Ottavio Caruso wrote:

I have a Bash script that renames files after being listened to:

FILE=$(ls -tr|head -n 1) # get the oldest file
aplay $FILE # where $FILE is a wav file
mv $FILE $(date +"%Y%m%d_%H%M").wav

However the resulting file doesn't get its timestamp changed, so I have to:

FILE=$(ls -tr|head -n 1
aplay $FILE
touch $FILE
mv $FILE $(date +"%Y%m%d_%H%M").wav

which is fine, but I wonder if there is a way for "mv" to update the timestamp without using "touch".

No, 'touch' is the command to use if you want to update time-stamps.

What you may also want to consider...
Quote all uses of $FILE.
Use 'mv -i' to prevent name clashes with your name's minute resolution.
Keep the output of 'date' in a variable and use it also for 'touch -d'.
You can also use 'stat' to get the file date(s) (access, modification,
change) directly from the file without 'date', so that you may choose
whether to use initial date of the file or the date of last playing it.

Janis

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 20/07/2023 um 09:14 schrieb Janis Papanagnou:

On 20.07.2023 11:01, Ottavio Caruso wrote:

I have a Bash script that renames files after being listened to:

FILE=$(ls -tr|head -n 1) # get the oldest file
aplay $FILE # where $FILE is a wav file
mv $FILE $(date +"%Y%m%d_%H%M").wav

However the resulting file doesn't get its timestamp changed, so I have to: >>
FILE=$(ls -tr|head -n 1
aplay $FILE
touch $FILE
mv $FILE $(date +"%Y%m%d_%H%M").wav


which is fine, but I wonder if there is a way for "mv" to update the
timestamp without using "touch".

No, 'touch' is the command to use if you want to update time-stamps.

What you may also want to consider...
Quote all uses of $FILE.
Use 'mv -i' to prevent name clashes with your name's minute resolution.
Keep the output of 'date' in a variable and use it also for 'touch -d'.
You can also use 'stat' to get the file date(s) (access, modification, change) directly from the file without 'date', so that you may choose
whether to use initial date of the file or the date of last playing it.

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new
file, hence modifying creation date.


--
Ottavio Caruso

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 20 Jul 2023 14:11:59 +0000, Ottavio Caruso wrote:

Am 20/07/2023 um 09:14 schrieb Janis Papanagnou:

On 20.07.2023 11:01, Ottavio Caruso wrote:

I have a Bash script that renames files after being listened to:

FILE=$(ls -tr|head -n 1) # get the oldest file
aplay $FILE # where $FILE is a wav file
mv $FILE $(date +"%Y%m%d_%H%M").wav

However the resulting file doesn't get its timestamp changed, so I have to: >>>
FILE=$(ls -tr|head -n 1
aplay $FILE
touch $FILE
mv $FILE $(date +"%Y%m%d_%H%M").wav


which is fine, but I wonder if there is a way for "mv" to update the
timestamp without using "touch".

No, 'touch' is the command to use if you want to update time-stamps.

What you may also want to consider...
Quote all uses of $FILE.
Use 'mv -i' to prevent name clashes with your name's minute resolution.
Keep the output of 'date' in a variable and use it also for 'touch -d'.
You can also use 'stat' to get the file date(s) (access, modification,
change) directly from the file without 'date', so that you may choose
whether to use initial date of the file or the date of last playing it.

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new file, hence modifying creation date.

No, under Unix, you would /NOT/ expect that mv(1) would create a new
file, nor would it modify a "creation date".

Unless moving from one filesystem to another, mv(1) just modifies the
name of the file, and leaves the inode alone. Under this scenario, there's
no "new file", just changes to one (or two) directories.

If you move a file (or directory) from one filesystem to another, mv(1)
acts like a cp(1), followed by an unlink(1). In this case, it /will/
create a new file, and a new inode for that file.

However, mv(1) /does not/ (on Unix file systems) update a "creation time". Some, more recent, filesystems include such a timestamp, as do the Microsoft filesystems, but traditional Unix filesystems only include three timestamps:
1) the time of last access to the file data (the "atime"),
2) the time of last modification of the file data (the "mtime"), and
3) the time of last status change (the "ctime")

HTH
--
Lew Pitcher
"In Skills We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20.07.2023 16:11, Ottavio Caruso wrote:

[...] Has this been "mv" standard behaviour from the UNIX days? You
would expect that renaming a file literally creates a new file, hence modifying creation date.

Well, as far as I am concerned we're still at least in the "Unix" days.
But yes, that's how I remember 'mv' to have always been. And note that
a 'mv' is just _renaming_ the file (i.e. changing the directory entry),
not creating a new file. At least I would expect (in the Unix world)
that a file is efficiently renamed [*] instead of being newly created.
[**] Usually I'm not very much interested when a file got renamed, but
your mileage may, vary of course.

Janis

[*] Note: at least if the file is/remains on the same file system.

[**] In earlier times it may (on MS DOS) have been differently, but
memories are faint and I just recall a lot of inefficiencies on the
DOS platform (especially with files and processes).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 20 Jul 2023 10:11:59 -0400, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new file, hence modifying creation date.

It does not create a new file unless the source and destination directories
are in different file systems.

Consider hard links, two file names pointing to the same inode. Moving one
of them has no affect on the other. The file has not been changed, just one
of the names pointing to the inode. Same logic is used when there is only one file name.

Regards, Dave Hodgins

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-07-20, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:

which is fine, but I wonder if there is a way for "mv" to update the timestamp without using "touch".

At the operating system level, a rename and touch are operations on
different objects. Renaming a file operates on a directory (or two directories). Touching a file operates on the file.

There is no locking scheme for doing that atomically: operating
on an object /and/ on the directories in which its name appears.

Even if a utility existed which touches and moves in a single
command, a program executing in parallel with that utility would
be able to observe the changes separately; it would notice that
the modification time of the file has updated, but the file
has not yet been renamed, or vice versa.

(Or amy I wrong? Is it doable in some Unix by putting a mandatory
lock on the directories involved, and the object?)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-07-20, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new file, hence modifying creation date.

Files do not have a "creation date" in Unix, only a modification time.

Files have "creation date" in, for example, Microsoft Windows. That date
is preserved by Microsoft Windows when you rename a file.

If a system has separate creation and modification dates, it would
make a certain amount of sense to touch the modification date if
the file is renamed. You could argue for that requirement without being automatically identified as a goofball. But if the creation date were
reset by the act of renaming, that would be pretty reprehensible.

Ideally, files should have a durable creation date that survives
even if they are moved from one system to another (possibly
a different OS).

Some file formats have that. Even if copying a JPEG from your
phone or camera to a PC destroys the creation date of the file,
the meta-data has the time and date the shot was taken.

The Git version control system tracks the time when every commit was
initially authored. That author date sticks even when a commit is
amended or cherry-picked into other branches, though the commit date is
reset to current.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 20 Jul 2023 15:12:36 +0000, Lew Pitcher wrote:

On Thu, 20 Jul 2023 14:11:59 +0000, Ottavio Caruso wrote:

[snip]

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new
file, hence modifying creation date.

No, under Unix, you would /NOT/ expect that mv(1) would create a new
file, nor would it modify a "creation date".

For what it's worth, you can read the source code for various versions
of the Unix mv(1) command. For instance, the source code for mv(1) from
Seventh Edition Unix can be found at
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/mv.c
That version only uses the link(2) and unlink(2) syscalls, meaning
that Seventh Edition Unix mv(1) would not have been able to move files
or directories between filesystems.

HTH
--
Lew Pitcher
"In Skills We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 20 Jul 2023 17:09:37 -0000 (UTC), Kaz Kylheku wrote:

On 2023-07-20, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new
file, hence modifying creation date.

Files do not have a "creation date" in Unix, only a modification time.

Glad I run linux then:
$ cat /etc/release
Mageia release 9 (Cauldron) for x86_64

for ARG in w x y z ; do echo -n " -$ARG " ;\
stat --format=%$ARG /etc/profile ; done ;\
man stat | grep human-

-w 2023-03-16 20:43:32.784828906 -0500
-x 2023-07-20 03:11:22.485829606 -0500
-y 2023-01-02 12:37:29.982724141 -0600
-z 2023-03-16 20:43:32.784828906 -0500
%w time of file birth, human-readable; - if unknown
%x time of last access, human-readable
%y time of last data modification, human-readable
%z time of last status change, human-readable

$ stat --version
stat (GNU coreutils) 9.1
Copyright (C) 2022 Free Software Foundation, Inc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.07.2023 07:55, Bit Twister wrote:

On Thu, 20 Jul 2023 17:09:37 -0000 (UTC), Kaz Kylheku wrote:

On 2023-07-20, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new >>> file, hence modifying creation date.

Files do not have a "creation date" in Unix, only a modification time.

Glad I run linux then:

I am also running Linux but get (for some system file, and as I
expected) a '-' for "creation date"

-w -
-x 2022-08-04 23:42:28.296526972 +0200
-y 2022-08-04 23:42:28.296526972 +0200
-z 2022-08-04 23:42:28.296526972 +0200
%w Time of file birth, human-readable; - if unknown
%x Time of last access, human-readable
%y Time of last modification, human-readable
%z Time of last change, human-readable


Janis

$ cat /etc/release
Mageia release 9 (Cauldron) for x86_64

for ARG in w x y z ; do echo -n " -$ARG " ;\
stat --format=%$ARG /etc/profile ; done ;\
man stat | grep human-

-w 2023-03-16 20:43:32.784828906 -0500
-x 2023-07-20 03:11:22.485829606 -0500
-y 2023-01-02 12:37:29.982724141 -0600
-z 2023-03-16 20:43:32.784828906 -0500
%w time of file birth, human-readable; - if unknown
%x time of last access, human-readable
%y time of last data modification, human-readable
%z time of last status change, human-readable

$ stat --version
stat (GNU coreutils) 9.1
Copyright (C) 2022 Free Software Foundation, Inc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 20/07/2023 um 17:09 schrieb Kaz Kylheku:

Files do not have a "creation date" in Unix, only a modification time.

If that is the case, how about:

$ man ls

--time=WORD
change the default of using modification times;
access time
(-u): atime, access, use; change time (-c): ctime,
status; birth time: birth, creation;


--
Ottavio Caruso

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bit Twister <BitTwister@mouse-potato.com> writes:

On Thu, 20 Jul 2023 17:09:37 -0000 (UTC), Kaz Kylheku wrote:

On 2023-07-20, Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new >>> file, hence modifying creation date.

Files do not have a "creation date" in Unix, only a modification time.

Glad I run linux then:
$ cat /etc/release
Mageia release 9 (Cauldron) for x86_64

for ARG in w x y z ; do echo -n " -$ARG " ;\
stat --format=%$ARG /etc/profile ; done ;\
man stat | grep human-

-w 2023-03-16 20:43:32.784828906 -0500
-x 2023-07-20 03:11:22.485829606 -0500
-y 2023-01-02 12:37:29.982724141 -0600
-z 2023-03-16 20:43:32.784828906 -0500
%w time of file birth, human-readable; - if unknown
%x time of last access, human-readable
%y time of last data modification, human-readable
%z time of last status change, human-readable

$ stat --version
stat (GNU coreutils) 9.1
Copyright (C) 2022 Free Software Foundation, Inc.

From `info coreutils 'file timestamps'`:

Standard POSIX files have three timestamps: the access timestamp
(atime) of the last read, the modification timestamp (mtime) of
the last write, and the status change timestamp (ctime) of the
last change to the file’s meta-information. Some file systems
support a fourth time: the birth timestamp (birthtime) of when
the file was created; by definition, birthtime never changes.

So the presence of the "birth" time is a property of the file system,
not necessarily of the OS (and the coreutils "ls" and "stat" commands
are able to access it somehow).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20.07.23 16:11, Ottavio Caruso wrote:

>Thanks, but it sucks. Has this been "mv" standard behaviour from the
>UNIX days? You would expect that renaming a file literally creates a new
>file, hence modifying creation date.

As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B". Even brain-dead systems don't do that.

Regards

Frank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.07.2023 12:18, Frank Winkler wrote:

On 20.07.23 16:11, Ottavio Caruso wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new
file, hence modifying creation date.

As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B". Even brain-dead systems don't do that.

I can see reasons for both interpretations, so I cannot chime in with
this heavy wording. After all the meta-data "operates" on a technical
level (as opposed to a semantical one); new data is physically created
(whether a copy or new original data) so the time stamp changes. The
system functions (man 2) used by the commands (man 1) also reflect the meta-data changes. I suppose how people think about it depends on their
typical use.

Myself I use mostly 'cp' without option to know when the copy had been
made. If I want the same file on a different place I use 'ln' (usually
hard links). Otherwise, if I intend to change the copy anyway, the
date of the original file becomes meaningless. But sometimes I use -p, especially as an implicit option of '-a' or an explicit 'cp -pr' in
backup or workspace or test contexts. You can have only one default.
Whether it's a "long standing misfeature" (as said elsethread) or not
lies in the eye of the beholder.

Myself I am more concerned about 'mv -i' vs. 'mv', and when using it
(and not only interactively) I got used to always type the former for
safety reasons. (Just to mention another of the basic file commands
and its [very much subjectively] "mis-featured" defaults.)

In both cases, a _simple option_ allows your preferred solution.[*]

Janis

[*] And this reminds me the pathological case where there's no short
option available; remember the 'ls --ignore-fail-on-non-empty' from
a thread one year ago? - Compared to that 'cp -p' and 'mv -i' are
trivialities.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Frank Winkler <usenet@f.winkler-ka.de> writes:

On 20.07.23 16:11, Ottavio Caruso wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new
file, hence modifying creation date.

As many other people already said, that assumption is wrong. And to go one step further, IMO it rather sucks that UNIX "cp" _does_ update the modification date unless using "-p". I never understood why it behaves this way as the content is untouched and why B should have a different time
stamp than A after "cp A B". Even brain-dead systems don't do that.

To some extent it comes down to the name used. No file systems that I
know of really note a modification time in the sense of the file being
actually changed; they note a "write time". After "cp A B" B is freshly written but has (in some sense) not been modified.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Frank Winkler <usenet@f.winkler-ka.de> writes:

On 20.07.23 16:11, Ottavio Caruso wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new
file, hence modifying creation date.

As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B". Even brain-dead systems don't do that.

So use "cp -p". (I usually do.)

After "cp A B", B is a new file (whose contents happen to match the
contents of A). It's similar to "cat A > B".

If I have two files with identical contents, their timestamps refer to
the files, not to their contents. If A and B are different, I modify B,
and B's new contents happen to be identical to A's contents, I don't
expect B's timestamps to reflect that.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

[*] And this reminds me the pathological case where there's no short
option available; remember the 'ls --ignore-fail-on-non-empty' from
a thread one year ago? - Compared to that 'cp -p' and 'mv -i' are trivialities.

"--ignore-fail-on-non-empty" is an option for rmdir, not ls.

And it can be abbreviated to "--i" (but not to "-i").

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.07.2023 23:09, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

[*] And this reminds me the pathological case where there's no short
option available; remember the 'ls --ignore-fail-on-non-empty' from
a thread one year ago? - Compared to that 'cp -p' and 'mv -i' are
trivialities.

"--ignore-fail-on-non-empty" is an option for rmdir, not ls.

(Right; what did I think?!)

And it can be abbreviated to "--i" (but not to "-i").

This is interesting! - Curiously I tried that with other long options
and it seems you can generally abbreviate long options to the point of unambiguity. - I didn't know that. Learned something new, thanks!

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-07-21, Frank Winkler <usenet@f.winkler-ka.de> wrote:

On 20.07.23 16:11, Ottavio Caruso wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new
file, hence modifying creation date.

As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B".

- Because it often has different permissions and ownership, too.

- Because you might later want to know the time when B was copied.

In order for cp to set the modification time on B, it has to overwrite
the mofication time which B already has naturally. That perpetrates a
kind of lie. The object B did not even exist at the time indicated by
its modification time stamp.

The model is very clear: cp just replicates the content without
any meta-data. All meta-data updates are opt-in. Command line
OPT-ions for OPT-in behavior; imagine that!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-07-22, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 22.07.2023 08:13, Kaz Kylheku wrote:

The model is very clear: cp just replicates the content without
any meta-data. All meta-data updates are opt-in.

Can you explain that "without any meta-data" part?

My understanding is that cp(1) uses write(2) and that this system
call will generally update the modification time meta-data on the
file.

Yes. So that is the new object's own meta-data, not a replica
of any other object's meta-data.

(Any option to "preserve" (i.e. take over) the time from the
original file would need separate system calls. - Is that what you
meant?)

Yes.

Also, by the way, we cannot copy all attributes of A to B,
otherwise we do not have a copy.

If we copy so many attributes of A to B that A and B are
indistinguishable, it means that A and B are the same
object; we do not have two objects.

Therfore, a copy operation must necessarily leave
some attributes uncopied.

If, say, cp were to replicate the inode number (one of the
attributes of a file), then it would be linking and not copying.

:)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22.07.2023 08:13, Kaz Kylheku wrote:

The model is very clear: cp just replicates the content without
any meta-data. All meta-data updates are opt-in.

Can you explain that "without any meta-data" part?

My understanding is that cp(1) uses write(2) and that this system
call will generally update the modification time meta-data on the
file. (Any option to "preserve" (i.e. take over) the time from the
original file would need separate system calls. - Is that what you
meant?)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/21/2023 4:59 AM, Ottavio Caruso wrote:

Am 20/07/2023 um 17:09 schrieb Kaz Kylheku:

Files do not have a "creation date" in Unix, only a modification time.

If that is the case, how about:

$ man ls

     --time=WORD
              change the default of  using  modification  times;
        access  time
              (-u): atime, access, use; change time (-c): ctime,
        status; birth time: birth, creation;

That option changes which of the file's timestamps to display. It
doesn't change them.

--
Wayne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/20/2023 10:11 AM, Ottavio Caruso wrote:

...
Thanks, but it sucks. Has this been "mv" standard behaviour from the UNIX days? You
would expect that renaming a file literally creates a new file, hence modifying
creation date.

You would only expect that if using DOS filesystem. For early DOS, the
file's name decided where on the disk it would reside, so if you renamed
a file (to a different directory), the file would be copied (thus creating
a new file) and the original one would be deleted. For Unix, the filesystems since the Berkeley Fast File System identifies files with a number called
the file's inode (in POSIX, "serial") number. This number uniquely identifies files within a single file system. The name of the file is stored separately in a directory file someplace. A directory is basically a two-column table used to find a file's inode number, given its name.

That said, if you mv a file from one file system to a different one, the
file is copied to the new file system and deleted from the original one. (That's a bit simplified but essentially true.) So in that case, you
do get an updated creation timestamp.

This is why a local mv (within a filesystem) does not need read permission
to rename a file, you only need write permission on the directory/directories. (And "x", but that's another story.)

But if you mv a file to a different filesystem, you do need read permission
and the file is copied, thus creating a new file.

Hope that helps!

--
Wayne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kaz Kylheku <864-117-4973@kylheku.com> writes:

On 2023-07-21, Frank Winkler <usenet@f.winkler-ka.de> wrote:

On 20.07.23 16:11, Ottavio Caruso wrote:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a new >> >file, hence modifying creation date.

As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the
modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B".

- Because it often has different permissions and ownership, too.

- Because you might later want to know the time when B was copied.

In order for cp to set the modification time on B, it has to overwrite
the mofication time which B already has naturally. That perpetrates a
kind of lie. The object B did not even exist at the time indicated by
its modification time stamp.

Yes. And when there is a "birth" time, the file can be marked as
accessed and modified before it even existed.

mcp does this by default default which is not what I want from a "copy".

The model is very clear: cp just replicates the content without
any meta-data. All meta-data updates are opt-in. Command line
OPT-ions for OPT-in behavior; imagine that!

cp does not update it (in any explicit way) but the modification time is updated by the system without opt-in. It's meta-data replication that
is opt-in.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Bacarisse wrote:

No file systems that I
know of really note a modification time in the sense of the file being actually changed; they note a "write time".

The modification time records when the contents of the file were
modified. The contents can be changed by other operations than writing.
In particular, truncation will modify it (including "truncation" to a
larger size using truncate() - the extra bytes have not been "written"
but will be read as null bytes, so the file's contents have effectively changed).

After "cp A B" B is freshly
written but has (in some sense) not been modified.

It makes more sense if you think of what is being done here in terms of
the low-level operations that cp performs, rather than the overall
result.

The first thing cp does is creat("B", 0666). If B already exists,
this truncates it (which changes the modification time); if B doesn't
exist it is created as an empty file (which sets all three/four
timestamps to the current time).

Then cp reads data from A and writes it to B. These writes change
the modification time of B again.

--
Geoff Clare <netnews@gclare.org.uk>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:

Ben Bacarisse wrote:

No file systems that I
know of really note a modification time in the sense of the file being
actually changed; they note a "write time".

The modification time records when the contents of the file were
modified.

I don't think a file has not changed in away would be seen (by
beginners) as having been modified. But:

The contents can be changed by other operations than writing.
In particular, truncation will modify it (including "truncation" to a
larger size using truncate() - the extra bytes have not been "written"
but will be read as null bytes, so the file's contents have effectively changed).

Yes, that a good point, and is presumably why it's hard to come up with a
word that really fits.

After "cp A B" B is freshly
written but has (in some sense) not been modified.

It makes more sense if you think of what is being done here in terms of
the low-level operations that cp performs, rather than the overall
result.

I know, of course, exactly what's going on, and so I know what a
modification time really means. I was only pointing out that the term
often causes confusion because not everyone does. It's a shame that, as
you say, the word make more sense when you know more. A word that makes
sense to the uninitiated would be preferable, but is probably impossible.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Ottavio" == Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:

Ottavio> Thanks, but it sucks. Has this been "mv" standard behaviour
Ottavio> from the UNIX days? You would expect that renaming a file
Ottavio> literally creates a new file, hence modifying creation date.

Classic Unix filesystems do *not* have a "creation date". They have a
"ctime" field, which updates when the file is opened for write, or the
metadata about the file has changed (name, number of links, and so on).

Renaming a file traditionally has updated ctime, but left atime (access)
and mtime (contents-modified) alone.


--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a
new file, hence modifying creation date.

I would not expect that. Analogously, when a person changes name
(e.g. upon marriage) it’s the same person under a different name; no new person has been created.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <wwv8raxk7me.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> wrote:

Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:

Thanks, but it sucks. Has this been "mv" standard behaviour from the
UNIX days? You would expect that renaming a file literally creates a
new file, hence modifying creation date.

I would not expect that. Analogously, when a person changes name
(e.g. upon marriage) its the same person under a different name; no new >person has been created.

Agreed, although there are various nitpicks I could pick with that
statement, if I were so inclined.

But the real point here, which has been alluded to by various posters (but
not stated explicitly), is that many new users (including, I believe, OP) assume that the "c" in "ctime" stands for "creation". In fact, it doesn't.
It stands for "change" - specifically, an inode change, as opposed to a
data change.

And, in fact, when you rename a file (*), "ctime" *is* updated. "mtime" isn't.

(*) Note that, at the nuts-and-bolts level, in Unix terms, a "rename"
always boils down to a link followed by an unlink.

Finally, note to OP: There's almost certainly a better (more reliable) way
to do whatever it is you're trying to do, than relying on file access
times. I speak from experience when I say that that road leads to
disaster.

--
To most Christians, the Bible is like a software license. Nobody
actually reads it. They just scroll to the bottom and click "I agree."

- author unknown -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This part made me curious...

On 30.07.2023 13:49, Kenny McCormack wrote:

(*) Note that, at the nuts-and-bolts level, in Unix terms, a "rename"
always boils down to a link followed by an unlink.

Inspecting the system log file during a file "rename" invoked by mv(1)
I can only spot a rename(2) system call (but no link(2) or unlink(2)).

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-07-30, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

Classic Unix filesystems do *not* have a "creation date". They have a "ctime" field, which updates when the file is opened for write, or the metadata about the file has changed (name, number of links, and so on).

Renaming a file traditionally has updated ctime,

... because it was implemented as a sequence of link(2) and unlink(2),
which touched the inode's link count.

I have a vague memory that the atomicity (or lack thereof) of the
later rename(2) system call was a much discussed topic, but I don't
remember what's the status on modern operating systems.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.07.2023 14:33, Christian Weisgerber wrote:

On 2023-07-30, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

Classic Unix filesystems do *not* have a "creation date". They have a
"ctime" field, which updates when the file is opened for write, or the
metadata about the file has changed (name, number of links, and so on).

Renaming a file traditionally has updated ctime,

... because it was implemented as a sequence of link(2) and unlink(2),
which touched the inode's link count.

I have a vague memory that the atomicity (or lack thereof) of the
later rename(2) system call was a much discussed topic, but I don't
remember what's the status on modern operating systems.

I think the "later" and the "modern" should be put in a quantified
age context. My Stevens' APUE from 1993 (that's three decades ago)
already describes rename(2) (and also mentions POSIX.1 changes).
An older Unix book (based on UNIX Version 7) from 1984 didn't have
it listed.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ua5pko$2uu8g$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

This part made me curious...

On 30.07.2023 13:49, Kenny McCormack wrote:

(*) Note that, at the nuts-and-bolts level, in Unix terms, a "rename"
always boils down to a link followed by an unlink.

Inspecting the system log file during a file "rename" invoked by mv(1)
I can only spot a rename(2) system call (but no link(2) or unlink(2)).

Obviously, somebody was going to post that.

But I think even lower, at the real nuts&bolts level, rename is doing the equivalent of link/unlink. The point of making rename a system call was to make it possible to make certain guarantees of atomicity.

--
Modern Christian: Someone who can take time out from using Leviticus
to defend homophobia and Exodus to plaster the Ten Commandments on
every school and courthouse to claim that the Old Testament is merely
"ancient laws" that "only applies to Jews".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

merlyn@stonehenge.com (Randal L. Schwartz) writes:

"Ottavio" == Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:

Ottavio> Thanks, but it sucks. Has this been "mv" standard behaviour
Ottavio> from the UNIX days? You would expect that renaming a file
Ottavio> literally creates a new file, hence modifying creation date.

Classic Unix filesystems do *not* have a "creation date".

That depends on what you call classic. The classic paper on Unix -- the
one in the 1978 special volume of the Bell Systems Technical Journal --
say that a file's i-node includes:

(v) time of creation, last use, and modification

but this was no longer true even a year or two later. Unfortunately the
field name stuck.

Why the change? I suspect because backups need to know when this
important i-node data has changed and it was too late to add an extra
time field to an i-node.

They have a
"ctime" field, which updates when the file is opened for write, or the metadata about the file has changed (name, number of links, and so
on).

Except that ctime does not record when the atime is changed. This may
be one of those things that goes without saying, but ctime is often
referred to as when the i-node was last updated and it's not exactly
that.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

gazelle@shell.xmission.com (Kenny McCormack) writes:

But the real point here, which has been alluded to by various posters (but not stated explicitly), is that many new users (including, I believe, OP) assume that the "c" in "ctime" stands for "creation". In fact, it doesn't. It stands for "change" - specifically, an inode change, as opposed to a
data change.

That's a new interpretation. In the original paper on Unix, the i-node
is described as having a creation time. The field names, st_ctime,
st_mtime and st_atime were chosen with these meanings. When (very soon
after) a new kind of time had to be recorded, st_ctime was re-purposed.

So what the "c" in ctime stands for has changed. It's no wonder people
are confused because atime, mtime and ctime are so obvious. Had it
originally been used for its later purpose, I doubt it would have been
called ctime.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-07-30, Christian Weisgerber <naddy@mips.inka.de> wrote:

On 2023-07-30, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

Classic Unix filesystems do *not* have a "creation date". They have a
"ctime" field, which updates when the file is opened for write, or the
metadata about the file has changed (name, number of links, and so on).

Renaming a file traditionally has updated ctime,

... because it was implemented as a sequence of link(2) and unlink(2),
which touched the inode's link count.

I have a vague memory that the atomicity (or lack thereof) of the
later rename(2) system call was a much discussed topic, but I don't
remember what's the status on modern operating systems.

It's funny that something which is probably 3 lines of C somewhere
keeps generating debate decades later.

If every decision in every 3 lines came with the threat of debate
decades later, I'd be paralyzed from coding anything. :)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kenny McCormack wrote:

But the real point here, which has been alluded to by various posters (but not stated explicitly), is that many new users (including, I believe, OP) assume that the "c" in "ctime" stands for "creation". In fact, it doesn't. It stands for "change" - specifically, an inode change, as opposed to a
data change.

And, in fact, when you rename a file (*), "ctime" *is* updated.

Some systems update it, some don't. It may well be an old SysV v. BSD difference, as Solaris updates it but macOS does not.

--
Geoff Clare <netnews@gclare.org.uk>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30.07.2023 18:03, Kenny McCormack wrote:

In article <ua5pko$2uu8g$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

This part made me curious...

On 30.07.2023 13:49, Kenny McCormack wrote:

(*) Note that, at the nuts-and-bolts level, in Unix terms, a "rename"
always boils down to a link followed by an unlink.

Inspecting the system log file during a file "rename" invoked by mv(1)
I can only spot a rename(2) system call (but no link(2) or unlink(2)).

Obviously, somebody was going to post that.

But I think even lower, at the real nuts&bolts level, rename is doing the equivalent of link/unlink. The point of making rename a system call was to make it possible to make certain guarantees of atomicity.

If atomicity is the topic then a statement "always boils down to a link followed by an unlink" makes even less sense. But okay, YMMV.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-07-31, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:

And, in fact, when you rename a file (*), "ctime" *is* updated.

Some systems update it, some don't. It may well be an old SysV v. BSD difference, as Solaris updates it but macOS does not.

FreeBSD and OpenBSD do update it.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <avmkpj-up8.ln1@ID-313840.user.individual.net>,
Geoff Clare <netnews@gclare.org.uk> wrote:

Some systems update it, some don't. It may well be an old SysV v. BSD >difference, as Solaris updates it but macOS does not.

On Omnios (illumos) stat(1) lists an updated ctime on ZFS and tmpfs(4FS).
With ZFS stat(1) reports a birthtime.

John
groenveld@acm.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 30.07.2023 18:03, Kenny McCormack wrote:

But I think even lower, at the real nuts&bolts level, rename is doing
the equivalent of link/unlink. The point of making rename a system
call was to make it possible to make certain guarantees of atomicity.

If atomicity is the topic then a statement "always boils down to a link followed by an unlink" makes even less sense. But okay, YMMV.

“rename is link followed by unlink, but atomic” doesn’t reflect what happens with directories, where you need to add an additional unlink
followed by link to reflect the overall outcome (at least in traditional
Unix filesystsem).

It’s also troublesome as an explanatory model in filesystems which don’t support hard links (i.e. which can’t have two names for one file
existing at once).

Finally it’s not a great model when talking to an audience which isn’t familiar or comfortable with the idea of multiple names for a single
file.

With those caveats in mind, though, I agree with Kenny, and the reason
for that is that you can still see reflections of the link+unlink design (generally surrounded by a lot of additional complexity) in some modern
kernel implementations.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Christian Weisgerber wrote:

On 2023-07-31, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:

And, in fact, when you rename a file (*), "ctime" *is* updated.

Some systems update it, some don't. It may well be an old SysV v. BSD
difference, as Solaris updates it but macOS does not.

FreeBSD and OpenBSD do update it.

Thanks. I suppose that means either the macOS rename() internals
didn't come from FreeBSD or there has been a change in FreeBSD since
Apple used it as the basis for OS X.

--
Geoff Clare <netnews@gclare.org.uk>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <o5anpj-nh6.ln1@ID-313840.user.individual.net>,
Geoff Clare <netnews@gclare.org.uk> wrote:

Christian Weisgerber wrote:

On 2023-07-31, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:

And, in fact, when you rename a file (*), "ctime" *is* updated.

Some systems update it, some don't. It may well be an old SysV v. BSD
difference, as Solaris updates it but macOS does not.

FreeBSD and OpenBSD do update it.

Thanks. I suppose that means either the macOS rename() internals
didn't come from FreeBSD or there has been a change in FreeBSD since
Apple used it as the basis for OS X.

It isn't just the OS that is the variable. The underlying filesystem
matters, too. Having used a Mac myself, I know that the underlying
filesystem (HFS) is not really a regular Unix filesystem - it has its roots
in more PC-ish OSes (i.e., original Mac OS, FAT, HPFS/NTFS, etc). For
example (and be warned that I don't have access to a Mac at the moment to
test this, so my memory may be inaccurate), but my memory is that HFS
doesn't really support hard links (they are emulated in software). Also,
it is only case retentive (like NTFS), not case sensitive (like regular Unix/Linux filesystems).

Also, see the man page for renameat2(2), for another example of where the underlying fs matters.

--
I am not a troll.
Rick C. Hodgin
I am not a crook.
Rick M. Nixon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <86edkq9p2n.fsf@red.stonehenge.com>,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:

"Ottavio" == Ottavio Caruso <ottavio2006-usenet2012@yahoo.com> writes:

Ottavio> Thanks, but it sucks. Has this been "mv" standard behaviour
Ottavio> from the UNIX days? You would expect that renaming a file
Ottavio> literally creates a new file, hence modifying creation date.

Classic Unix filesystems do *not* have a "creation date". They have a >"ctime" field, which updates when the file is opened for write, or the >metadata about the file has changed (name, number of links, and so on).

I'm not sure about the "opened for write" bit. On a write(2),
sure, but not necessary an open(2); at least, this is not listed
in the man page as a call that updates `st_ctime`. A quick spin
through 4.4BSD's ufs leads me to believe `ctime` is only changed
with the inode is updated, but not on open.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ua5udp$2vbt2$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 30.07.2023 14:33, Christian Weisgerber wrote:

On 2023-07-30, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

Classic Unix filesystems do *not* have a "creation date". They have a
"ctime" field, which updates when the file is opened for write, or the
metadata about the file has changed (name, number of links, and so on).

Renaming a file traditionally has updated ctime,

... because it was implemented as a sequence of link(2) and unlink(2),
which touched the inode's link count.

I have a vague memory that the atomicity (or lack thereof) of the
later rename(2) system call was a much discussed topic, but I don't
remember what's the status on modern operating systems.

I think the "later" and the "modern" should be put in a quantified
age context. My Stevens' APUE from 1993 (that's three decades ago)
already describes rename(2) (and also mentions POSIX.1 changes).
An older Unix book (based on UNIX Version 7) from 1984 didn't have
it listed.

Research Unix up to the 7th Edition implemented `mv` as a pair
of system calls: `link` and then `unlink`. The introduction of
the 4.2BSD "fast filesystem" brought the `rename` system call
(really, this seems to have first showed up in 4.1c) which was
atomic. Curiously, post-7th Ed Unix, which reimported the 4BSD
kernel, seems to have eschewed the `rename(2)` system call.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <87wmyhwe25.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

gazelle@shell.xmission.com (Kenny McCormack) writes:

But the real point here, which has been alluded to by various posters (but >> not stated explicitly), is that many new users (including, I believe, OP)
assume that the "c" in "ctime" stands for "creation". In fact, it doesn't. >> It stands for "change" - specifically, an inode change, as opposed to a
data change.

That's a new interpretation. In the original paper on Unix, the i-node
is described as having a creation time. The field names, st_ctime,
st_mtime and st_atime were chosen with these meanings. When (very soon >after) a new kind of time had to be recorded, st_ctime was re-purposed.

It is true that the 1978 paper says that, as does the comment on
the `st_ctime` field in `sys/ino.h` in 7th Edition; `st_ctime`
was not present before that.

However, that is not the original Unix paper; the earlier 1974
paper published in CACM does not mention a ctime at all; instead
it just mentions "5. Time of last modification." Note that
mention of accessed time is also absent here. https://dsf.berkeley.edu/cs262/unix.pdf

Note that with respect to 7th Edition, both the comment and the
paperappear to be wrong. Looking at the kernel sources,
`di_ctime` is updated by `iupdat` in `usr/sys/iget.c` whenever
the `ICHG` flag is set on the inode; that flag is set in a
number of places (write, chmod, chown, link/unlink, etc) in
addition to the original file creation.

So what the "c" in ctime stands for has changed. It's no wonder people
are confused because atime, mtime and ctime are so obvious. Had it >originally been used for its later purpose, I doubt it would have been
called ctime.

It would seem that the `ctime` field in the inode has always had
a meaning very close to what we assume it to be in a modern
context; if it was ever _just_ the creation time, then that
would likely have been in an unreleased version of Unix and only
for a very short time indeed.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:

Christian Weisgerber wrote:

On 2023-07-31, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote: >>>> And, in fact, when you rename a file (*), "ctime" *is* updated.

Some systems update it, some don't. It may well be an old SysV v. BSD
difference, as Solaris updates it but macOS does not.

FreeBSD and OpenBSD do update it.

Thanks. I suppose that means either the macOS rename() internals
didn't come from FreeBSD or there has been a change in FreeBSD since
Apple used it as the basis for OS X.

My understanding is that MacOS was based on an older BSD (and other
sources), not on FreeBSD. FreeBSD and MacOS are siblings or cousins,
not parent and child.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.08.2023 09:40, Richard Kettlewell wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 30.07.2023 18:03, Kenny McCormack wrote:

But I think even lower, at the real nuts&bolts level, rename is doing
the equivalent of link/unlink. The point of making rename a system
call was to make it possible to make certain guarantees of atomicity.

If atomicity is the topic then a statement "always boils down to a link
followed by an unlink" makes even less sense. But okay, YMMV.

“rename is link followed by unlink, but atomic” doesn’t reflect what happens with directories, where you need to add an additional unlink
followed by link to reflect the overall outcome (at least in traditional
Unix filesystsem).

It’s also troublesome as an explanatory model in filesystems which don’t support hard links (i.e. which can’t have two names for one file
existing at once).

Same issue with cross-device links.

Generally I agree with you concerning directories and the general case
of hard links (whether non-supporting FS or cross-device applications).

Or similar a 'mv' when considering cross-device arguments (emulated by
cp/rm).

Finally it’s not a great model when talking to an audience which isn’t familiar or comfortable with the idea of multiple names for a single
file.

Speaking about "models", I wouldn't consider explaining rename(2) by
link(2) and unlink(2) (or explaining mv(1) by cp(1) and rm(1), just to
make my point clear) a sensible approach if it doesn't reflect reality
(which is optimized for the simple standard cases). If an "audience"
is operating/working on _that_ OS level it should IMO know the details
and differences of the supported actual cases. A model that gives the impression that an [atomic] system function is effectively built upon
more than one system function - thus conceptually/model-wise becoming non-atomic - I'd not consider a preferable description. Introducing
functions that aren't actually used to explain a function I also don't
consider sensible. (The formal part of the POSIX specs, for example,
doesn't mention them; they are unnecessary for understanding.) But as
I said upthread, mileages (obviously) vary.

With those caveats in mind, though, I agree with Kenny, and the reason
for that is that you can still see reflections of the link+unlink design (generally surrounded by a lot of additional complexity) in some modern kernel implementations.

Maybe. I currently have no systems other than Linux available. Though
the POSIX description should anyway suffice.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:

Thanks. I suppose that means either the macOS rename() internals
didn't come from FreeBSD or there has been a change in FreeBSD since
Apple used it as the basis for OS X.

My understanding is that MacOS was based on an older BSD (and other
sources), not on FreeBSD. FreeBSD and MacOS are siblings or cousins,
not parent and child.

At some point between NeXTStep and current macOS they upgraded from 4.x
BSD to FreeBSD.

https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/BSD/BSD.html

But this isn’t probably not directly relevant to the provenance of
rename(); the nuts and bolts are filesystem-dependent and HFS/HFS+ are
Apple code.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 01 Aug 2023 13:40:35 -0700, Keith Thompson wrote:

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:

Christian Weisgerber wrote:

On 2023-07-31, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote: >>>>> And, in fact, when you rename a file (*), "ctime" *is* updated.

Some systems update it, some don't. It may well be an old SysV v. BSD
difference, as Solaris updates it but macOS does not.

FreeBSD and OpenBSD do update it.

Thanks. I suppose that means either the macOS rename() internals
didn't come from FreeBSD or there has been a change in FreeBSD since
Apple used it as the basis for OS X.

My understanding is that MacOS was based on an older BSD (and other
sources), not on FreeBSD. FreeBSD and MacOS are siblings or cousins,
not parent and child.

macOS version history in WIKI has a section on Development outside Apple
that is consistent with what I have read and remember over the years.

en.wikipedia.org/wiki/MacOS_version_history

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely
expects users to be computer friendly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <uabr7k$3ospu$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[snip]
Speaking about "models", I wouldn't consider explaining rename(2) by
link(2) and unlink(2) (or explaining mv(1) by cp(1) and rm(1), just to
make my point clear) a sensible approach if it doesn't reflect reality
(which is optimized for the simple standard cases). If an "audience"
is operating/working on _that_ OS level it should IMO know the details
and differences of the supported actual cases. A model that gives the >impression that an [atomic] system function is effectively built upon
more than one system function - thus conceptually/model-wise becoming >non-atomic - I'd not consider a preferable description. Introducing
functions that aren't actually used to explain a function I also don't >consider sensible. (The formal part of the POSIX specs, for example,
doesn't mention them; they are unnecessary for understanding.) But as
I said upthread, mileages (obviously) vary.

It is illustrative here to look at the history of the call, and
when it was added in BSD (4.1c is when it first appeared). From sys/sys/ufs_syscalls.c, we can see the comment on `rename`:

/*
* Rename system call.
* rename("foo", "bar");
* is essentially
* unlink("bar");
* link("foo", "bar");
* unlink("foo");
* but ``atomically''. Can't do full commit without saving state in the
* inode on disk which isn't feasible at this time. Best we can do is
* always guarantee the target exists.
*
* Basic algorithm is:
*
* 1) Bump link count on source while we're linking it to the
* target. This also insure the inode won't be deleted out
* from underneath us while we work.
* 2) Link source to destination. If destination already exists,
* delete it first.
* 3) Unlink source reference to inode if still around.
* 4) If a directory was moved and the parent of the destination
* is different from the source, patch the ".." entry in the
* directory.
*
* Source and destination must either both be directories, or both
* not be directories. If target is a directory, it must be empty.
*/ (https://www.tuhs.org/cgi-bin/utree.pl?file=4.1cBSD/a/sys/sys/ufs_syscalls.c)

In order to understand the semantics here, it is important to
contextualize what "atomic" means in the context of filesystems:
this means that an operation with side effects cannot allow an
observer to see intermediate states, one either sees the new
state or the old state; whether the transition from one to the
other requires many steps is immaterial: the point is that this
invariant is maintained _with respect to the external
observer_.

A way to unify this with a mental model may be to describe it as
being multiple operations that happen in a critical section.

Here, the comment gives us a hint about the limitations: "Best
we can do is always guarantee the target exists." Note that
this implies that both the target _and_ source may exist if,
say, the system crashes in the middle of the syscall.

- Dan C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)