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

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

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

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

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"

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

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

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

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"

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.

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

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

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

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

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.

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.

--
I voted for Trump because I thought he'd make pussy grabbing legal.
I honestly don't see any other way America could be made great again.

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

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

--

Chris Elvidge, England
I AM NOT THE NEW DALAI LAMA

On 21.07.23 14:00, Chris Elvidge wrote:

>"cp A B" creates a new file 'B' so B has new modification time (unless
>overidden).

Creation, not modification.

>mcp : command not found - slackware and lmde5

I also don't know that one, neither on Solaris nor macOS nor Linux nor
whatever ;) ...

Regards

Frank

In article <khvaveFlvvnU2@mid.individual.net>,
Frank Winkler <usenet@f.winkler-ka.de> wrote:
>On 21.07.23 14:00, Chris Elvidge wrote:
>
> >"cp A B" creates a new file 'B' so B has new modification time (unless
> >overidden).
>
>Creation, not modification.

Yes. Everybody knows that. The point is: It is a historical misfeature.

> >mcp : command not found - slackware and lmde5
>
>I also don't know that one, neither on Solaris nor macOS nor Linux nor
>whatever ;) ...

Have neither you nor Chris heard of these wonderful pieces of software
called "package managers"? They're really cool, and you should look into
them. They are so cool - you just run them and they install new software
on your system that you didn't have before. What's even better is that
these package manager thingies *are* usually installed by default on your
Linux system(s), you don't even have to explicitly get and install them.
They just work. It is soooooooo kewl!

--
This is the GOP's problem. When you're at the beginning of the year
and you've got nine Democrats running for the nomination, maybe one or
two of them are Dennis Kucinich. When you have nine Republicans, seven
or eight of them are Michelle Bachmann.

On 21.07.23 14:24, Kenny McCormack wrote:

>Have neither you nor Chris heard of these wonderful pieces of software
>called "package managers"? They're really cool, and you should look into

Of course I have. But even with a package manager, I only install things
that I know of. And just as an example, MacPorts also doesn't seem to
know it:

frank@lmka-2cl377md6r:~$ which mcp
frank@lmka-2cl377md6r:~$ port search mcp
Warning: port definitions are more than two weeks old, consider updating
them by running 'port selfupdate'.
mcpp @2.7.2_6 (devel)
Alternative C/C++ preprocessor

R-MCMCpack @1.6-3_1 (R, science, math)
Markov Chain Monte Carlo (MCMC) package

R-mcmcplots @0.4.3 (R, science)
Functions for convenient plotting and viewing of MCMC output

R-MCPAN @1.1-21 (R, science, math)
Multiple contrast tests and simultaneous confidence intervals based on
normal approximation

R-ncvreg @3.14.1_1 (R, science, math)
Regularization paths for SCAD and MCP penalized regression models

wmcpuload @1.0.1_4 (sysutils, x11)
An lcd dockapp that displays the current cpuload

xdm @1.1.12 (x11)
X11 display manager with support for XDMCP, host chooser

xorg-libXdmcp @1.1.4 (x11, devel)
X.org libXdmcp

Found 8 ports.
frank@lmka-2cl377md6r:~$

I can try OpenCSW on a Solaris machine.

Regards

Frank

On 21/07/2023 13:24, Kenny McCormack wrote:
> In article <khvaveFlvvnU2@mid.individual.net>,
> Frank Winkler <usenet@f.winkler-ka.de> wrote:
>> On 21.07.23 14:00, Chris Elvidge wrote:
>>
>> >"cp A B" creates a new file 'B' so B has new modification time (unless
>> >overidden).
>>
>> Creation, not modification.
>
> Yes. Everybody knows that. The point is: It is a historical misfeature.
>
>> >mcp : command not found - slackware and lmde5
>>
>> I also don't know that one, neither on Solaris nor macOS nor Linux nor
>> whatever ;) ...
>
> Have neither you nor Chris heard of these wonderful pieces of software
> called "package managers"? They're really cool, and you should look into
> them. They are so cool - you just run them and they install new software
> on your system that you didn't have before. What's even better is that
> these package manager thingies *are* usually installed by default on your
> Linux system(s), you don't even have to explicitly get and install them.
> They just work. It is soooooooo kewl!
>

Slackpkg can't find it.
Neither can "apt search" nor "apt list" on LMDE5.

--

Chris Elvidge, England
I WILL NOT MESS WITH THE OPENING CREDITS

In article <khveq2FlvvnU3@mid.individual.net>,
Frank Winkler <usenet@f.winkler-ka.de> wrote:
>On 21.07.23 14:24, Kenny McCormack wrote:
>
> >Have neither you nor Chris heard of these wonderful pieces of software
> >called "package managers"? They're really cool, and you should look into
>
>Of course I have. But even with a package manager, I only install things
>that I know of. And just as an example, MacPorts also doesn't seem to
>know it:

There's also this really cool thing - called "google". You can find out
all kinds of stuff using it. It's really amazing.

Using this google thingie, you can learn about these things called "C
compilers" and "make" programs. Then you can learn about doing things
like:

./configure
make

--
Q: How much do dead batteries cost?

A: Nothing. They are free of charge.

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.

In article <khveq2FlvvnU3@mid.individual.net>,
Frank Winkler <usenet@f.winkler-ka.de> wrote:
>On 21.07.23 14:24, Kenny McCormack wrote:
>
> >Have neither you nor Chris heard of these wonderful pieces of software
> >called "package managers"? They're really cool, and you should look into
>
>Of course I have. But even with a package manager, I only install things
>that I know of. And just as an example, MacPorts also doesn't seem to
>know it:

BTW, just in case you're not just being deliberately obtuse, I put "mcp Linux"
into a search engine and got (inter alia):

https://www.unix.com/man-page/suse/1/mcp/

HTH

--
Elect a clown, expect a circus.

Am 21/07/2023 um 13:30 schrieb Kenny McCormack:
> There's also this really cool thing - called "google". You can find out
> all kinds of stuff using it. It's really amazing.

Google is for softy-softy gen Z snowflake fembois.

Real men use Gopher on BSD 4.2.

--
Ottavio Caruso

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.