On Tue, 11 Apr 2017 19:39:28 -0700 Philip Guenther <[email protected]> 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.
