Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

2017-04-13 Thread bytevolcano
On Tue, 11 Apr 2017 16:41:16 -0600
"Theo de Raadt"  wrote:

> > Note that I have noatime on this FS.  
> 
> Maybe we should remove this broken feature.
> 

I would love to know what is broken about it, so I can investigate
this and disable it on my systems if it's too risky for me to keep.

I almost never need the atime stamps, and none of the applications I
have run are broken by noatime, so I disable it where I do not need (or
want) atime updated every time a file is read.

My only reasons for having noatime there in the first place is to save
write cycles on the SSDs I use, and to improve performance on an older
system I run OpenBSD on. That being said, I do make backups regularly,
so I am happy to sacrifice some performance if need be.



Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

2017-04-11 Thread bytevolcano
On Tue, 11 Apr 2017 19:39:28 -0700
Philip Guenther  wrote:

> The 'issue' is that he's changing the parent of a directory and that
> means it has to update the ".." link inside the directory, so it
> alters the directory contents and the mtime is thus updated.

That explains a lot. I thought the ".." link was a dynamic OS-created
entity, rather than something that's actually in the FS.

Though this is inconsistent with preserving the mtime when moving the
directory across filesystems, which also changes the parent.

> 
> 
> If I hit this, I would have to reconsider why I'm using the mtime of
> the directory for whatever alternate purpose makes me want to preserve
> the timestamp here.  If changing that use case is too much effort,
> then I would just script the preservation and use "touch -r" to copy
> the timestamps to a placeholder file, do the move, then "touch -r"
> again to restore them.  Introducing a non-standard option for this
> particular case pushes the cost the wrong direction, IMO.

I agree with that logic to a large extent.

I was initially thinking a similar thing, but then I got the idea that,
since cp(1) has such an option to preserve the time stamps, it seems
logical for mv(1) to have a similar option as well, and it is such a
trivial thing to add.



Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

2017-04-11 Thread Philip Guenther
On Tue, Apr 11, 2017 at 6:53 PM, Bob Beck  wrote:
>
>> Note that I have noatime on this FS.
>
> then turn that off, or understand that things will not behave as you expect 
> them to with it on.

Nah, the noatime is a red herring, nicely smeared across the evidence
trail here.

The 'issue' is that he's changing the parent of a directory and that
means it has to update the ".." link inside the directory, so it
alters the directory contents and the mtime is thus updated.


If I hit this, I would have to reconsider why I'm using the mtime of
the directory for whatever alternate purpose makes me want to preserve
the timestamp here.  If changing that use case is too much effort,
then I would just script the preservation and use "touch -r" to copy
the timestamps to a placeholder file, do the move, then "touch -r"
again to restore them.  Introducing a non-standard option for this
particular case pushes the cost the wrong direction, IMO.


Philip Guenther



Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

2017-04-11 Thread Bob Beck

> Note that I have noatime on this FS.

then turn that off, or understand that things will not behave as you expect 
them to with it on. 




Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

2017-04-11 Thread bytevolcano
Sorry I was copying this out from a VM, so I ended up typing it up
wrong here:

$ mkdir Foo
$ touch -t 2101 Foo
$ ls -dlT Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
$ ls -dluT Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
$ mkdir Bar
$ mv Foo Bar/
$ ls -dlT Bar/Foo
drwxr-xr-x  2 bob  bob  512 Apr 12 07:55:30 2017 Bar/Foo
$ ls -dluT Bar/Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Bar/Foo

Running openbsd -current (Feb 26)

On Wed, 12 Apr 2017 08:37:37 +1000
 wrote:

> On Tue, 11 Apr 2017 16:54:29 +0200
> Ingo Schwarze  wrote:
> 
> > Hi,
> > 
> > bytevolc...@safe-mail.net wrote on Fri, Apr 07, 2017 at 12:25:10PM
> > +1000:
> >   
> > > Although mv(1) will preserve atime and mtime for moved directories
> > > if moved to a different file system, it doesn't preserve them when
> > > moved in the same file system.
> > 
> > Cannot reproduce.
> > 
> >$ mkdir Foo
> >$ touch -t 2101 Foo 
> >$ ls -dl Foo
> >   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
> >$ ls -dlu Foo
> >   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
> >$ mv Foo Bar
> >$ ls -dl Bar  
> >   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar
> >$ ls -dlu Bar
> >   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar  
> 
> I can:
> 
> $ mkdir Foo
> $ touch -t 2101 Foo
> $ ls -dlT Foo
> drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
> $ ls -dluT Foo
> drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
> $ mkdir Bar
> $ mv Foo Bar/
> $ ls -dlT Bar/Foo
> drwxr-xr-x  2 bob  bob  512 Apr 12 07:55:30 2017 Foo/Bar
> $ ls -dluT Bar/Foo
> drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo/Bar
> 
> Note that I have noatime on this FS.
> 
> > Sounds like a bad idea.  Do not add non-standard options to standard
> > utilities unless they are useful to a very unusual degree.  Even if
> > there is some corner case that you failed to describe, this seems
> > by far not important enough for adding an option.  
> 
> The problem I am solving here is that, when moving folders into other
> folders (often to clean up its parent a little and organise the FS),
> mv(1) does not preserve the time stamps of moved directories.
> 
> If I move the directory into another FS, this information is
> preserved.
> 
> > Besides, neither FreeBSD nor NetBSD have -p, so it would be an
> > egregious example of introducing gratuitious incompatibility.  
> 
> I don't see any gratuitious incompatibility here. The utility behaves
> exactly as before without the -p option, and will therefore be
> compatible with existing scripts.
> 
> It may help to modify the behaviour of rename(2), since there is
> nothing I see in the POSIX standard
> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html)
> about requiring the change in time stamps. The advantage is consistent
> behaviour across all applications rather than just mv(1).
> 



Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

2017-04-11 Thread Theo de Raadt
> Note that I have noatime on this FS.

Maybe we should remove this broken feature.



Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

2017-04-11 Thread bytevolcano
On Tue, 11 Apr 2017 16:54:29 +0200
Ingo Schwarze  wrote:

> Hi,
> 
> bytevolc...@safe-mail.net wrote on Fri, Apr 07, 2017 at 12:25:10PM
> +1000:
> 
> > Although mv(1) will preserve atime and mtime for moved directories
> > if moved to a different file system, it doesn't preserve them when
> > moved in the same file system.  
> 
> Cannot reproduce.
> 
>$ mkdir Foo
>$ touch -t 2101 Foo 
>$ ls -dl Foo
>   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
>$ ls -dlu Foo
>   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
>$ mv Foo Bar
>$ ls -dl Bar  
>   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar
>$ ls -dlu Bar
>   drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar

I can:

$ mkdir Foo
$ touch -t 2101 Foo
$ ls -dlT Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
$ ls -dluT Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo
$ mkdir Bar
$ mv Foo Bar/
$ ls -dlT Bar/Foo
drwxr-xr-x  2 bob  bob  512 Apr 12 07:55:30 2017 Foo/Bar
$ ls -dluT Bar/Foo
drwxr-xr-x  2 bob  bob  512 Jan  1 00:00:00 2000 Foo/Bar

Note that I have noatime on this FS.

> Sounds like a bad idea.  Do not add non-standard options to standard
> utilities unless they are useful to a very unusual degree.  Even if
> there is some corner case that you failed to describe, this seems
> by far not important enough for adding an option.

The problem I am solving here is that, when moving folders into other
folders (often to clean up its parent a little and organise the FS),
mv(1) does not preserve the time stamps of moved directories.

If I move the directory into another FS, this information is preserved.

> Besides, neither FreeBSD nor NetBSD have -p, so it would be an
> egregious example of introducing gratuitious incompatibility.

I don't see any gratuitious incompatibility here. The utility behaves
exactly as before without the -p option, and will therefore be
compatible with existing scripts.

It may help to modify the behaviour of rename(2), since there is
nothing I see in the POSIX standard
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html)
about requiring the change in time stamps. The advantage is consistent
behaviour across all applications rather than just mv(1).



Re: patch: mv(1): Add -p flag to preserve time stamps for moved directories

2017-04-11 Thread Ingo Schwarze
Hi,

bytevolc...@safe-mail.net wrote on Fri, Apr 07, 2017 at 12:25:10PM +1000:

> Although mv(1) will preserve atime and mtime for moved directories if
> moved to a different file system, it doesn't preserve them when moved
> in the same file system.

Cannot reproduce.

   $ mkdir Foo
   $ touch -t 2101 Foo 
   $ ls -dl Foo
  drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
   $ ls -dlu Foo
  drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Foo
   $ mv Foo Bar
   $ ls -dl Bar  
  drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar
   $ ls -dlu Bar
  drwxr-xr-x  2 schwarze  schwarze  512 Jan  1  2000 Bar

> This patch adds a "-p" flag as an extension to allow preserving the
> time stamps, whilst allowing mv(1) to retain POSIX behaviour without
> the flag.

Sounds like a bad idea.  Do not add non-standard options to standard
utilities unless they are useful to a very unusual degree.  Even if
there is some corner case that you failed to describe, this seems
by far not important enough for adding an option.

Besides, neither FreeBSD nor NetBSD have -p, so it would be an
egregious example of introducing gratuitious incompatibility.

Yours,
  Ingo