On Fri, 21 Jul 2023 08:00:26 -0400, Chris Elvidge <chris@mshome.net> wrote:

> On 21/07/2023 11:54, Kenny McCormack wrote:
>> In article <khv4chFlvvnU1@mid.individual.net>,
>> Frank Winkler <usenet@f.winkler-ka.de> wrote:
>> ...
>>> 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.
>
> "cp A B" creates a new file 'B' so B has new modification time (unless
> overidden).
>
> "mv A B" should really be advertised as "rename A B" (unless A and B are
> on different filesystems).

From "man mv" ...
NAME
mv - move (rename) files

>> Yes, that's a long standing misfeature. It is one of those: They picked
>> the wrong default in the beginning and every Unix "copy" program, from cp
>> to rsync, et al, has had to do the wrong thing by default ever since. You
>> need a command line option (-p or -a or something like that) in order to
>> get the sensible behavior.
>>
>> Note that "mcp" does the right thing by default. That's the only
>> exception to the above rule that I can think of.
>>
> mcp : command not found - slackware and lmde5

The mcp command is from the package mmv ...
URL : http://packages.qa.debian.org/m/mmv.html
Summary : Move/copy/append/link multiple files

Regards, Dave Hodgins

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 */

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 */

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

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!

On 2023-07-21, Chris Elvidge <chris@mshome.net> wrote:
> On 21/07/2023 11:54, Kenny McCormack wrote:
>> In article <khv4chFlvvnU1@mid.individual.net>,
>> Frank Winkler <usenet@f.winkler-ka.de> wrote:
>> ...
>>> 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.
>
> "cp A B" creates a new file 'B' so B has new modification time (unless
> overidden).
>
> "mv A B" should really be advertised as "rename A B" (unless A and B are
> on different filesystems).

mv would have the semantics of a rename, if a filesystem was represented
as a list of < path, object > pairs (which could be true of some
filesystems).

But in fact, due to the reality of the hierarchical directory structure
of the typical filesystems we use, a move between directories is a
relocation, because the object is put under a different parent.

If mv could be called rename, that would open up another opportunity
for a correction. Copying data is called moving, so cp could be renamed
to mv, like it wants to be!

That's consistent with "MOVE R3, R4" and memmove(dest, str, size).

:)

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

On 2023-07-21, Chris Elvidge <chris@mshome.net> wrote:
> mcp : command not found - slackware and lmde5

mcp seems to be something that was written by one

Vladimir Lanin <lanin@csd2.nyu.***>

in the year 1989 (or earlier).

mcp is one of the links (or symlinks) to a single executable.

It has four names: mmv, mcp, mad and mln, which implicitly specify a
default action of -x, -c, -a or -l.

It looks nice; why isn't it better known.

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

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

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

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

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

On 7/22/2023 2:25 AM, Kaz Kylheku wrote:
> On 2023-07-21, Chris Elvidge <chris@mshome.net> wrote:
>> mcp : command not found - slackware and lmde5
>
> mcp seems to be something that was written by one
>
> Vladimir Lanin <lanin@csd2.nyu.***>
>
> in the year 1989 (or earlier).
>
> mcp is one of the links (or symlinks) to a single executable.
>
> It has four names: mmv, mcp, mad and mln, which implicitly specify a
> default action of -x, -c, -a or -l.
>
> It looks nice; why isn't it better known.
>

IIRC, in System V, cp, mv, and ln were all links to a single executable.

--
Wayne

Am 22/07/2023 um 09:23 schrieb Wayne:
> On 7/22/2023 2:25 AM, Kaz Kylheku wrote:
>> On 2023-07-21, Chris Elvidge <chris@mshome.net> wrote:
>>> mcp : command not found - slackware and lmde5
>>
>> mcp seems to be something that was written by one
>>
>> Vladimir Lanin <lanin@csd2.nyu.***>
>>
>> in the year 1989 (or earlier).
>>
>> mcp is one of the links (or symlinks) to a single executable.
>>
>> It has four names: mmv, mcp, mad and mln, which implicitly specify a
>> default action of -x, -c, -a or -l.
>>
>> It looks nice; why isn't it better known.
>>
>
> IIRC, in System V, cp, mv, and ln were all links to a single executable.
>

They still are on Busybox.

--
Ottavio Caruso

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.

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>

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.

>>>>> "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

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/

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 -

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

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

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

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".

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.

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.