Option: restore parent folder date after deleting (or moving from it) content

[andry81]

Once again: pseudo-recursion during deletion is possible only for files selected in DirBranch mode. That's why I asked about your desire to separate the behavior (given the additional key) of 3 modes and pointed out that this separation doesn't look right, safe and expected for many users, i.e. I wouldn't approve of this key with _RecurseSubdirs.
The real recursion concerns considering the entire depth of folders, and since deletion doesn't have file filtering, then there can be no recursion as such.

As Dalai said it has nothing to do with DirBranch or TC. A directory timestamp does update by Windows itself. So the `_RecurseSubdirs` handles a real directory structure for timestamps restore.

[Fla$her]

Dalai didn't write at all about what we are discussing and didn't touch DirBranch at all.
It's like you don't want to get into what I'm writing. What does it have to do with subdirectories when they are deleted along with the selected folder? There is no point in such an option.

So the `_RecurseSubdirs`

Maybe you're confusing 'Subdirs' with 'High-level dirs'?

[andry81]

Dalai didn't write at all about what we are discussing and didn't touch DirBranch at all.

He/she said about the OS internals, which has nothing to do with TC, DirBranch or anything else in TC.

What does it have to do with subdirectories when they are deleted along with the selected folder?

Nothing, there is no such a problem, until config file is not deleted, which is kind of different story.

Maybe you're confusing 'Subdirs' with 'High-level dirs'?

Subdirs is tracked (or not tracked) for directory timestamp restore inside the root directory. The root directory is tracked for directory timestamp restore as declared in the `.wincmd.ini` config file in this root directory with `RestoreDirDateAfterDeletingContent=1` option.

<root>
|
+-- /dir1
|
+-- /dir2
|
+-- .wincmd.ini
# Config file with `RestoreDirDateAfterDeletingContent=1` option,
# tracks changes INSIDE <root> directory - /dir1 and /dir2 timestamps.
# With `RestoreDirDateAfterDeletingContent_RecurseSubdirs=1` it additionally tracks changes for directories
# in directories /dir1 and /dir2 recursively - /dir1/* and /dir2/* timestamps.

What else to say here?

[Fla$her]

He/she said about the OS internals, which has nothing to do with TC, DirBranch or anything else in TC.

I was responding to your suggestion with a recursion to restore the date. What does Dalai have to do with this? Nothing.
I also gave an explanation where recursion relative to the current directory can be justified. And this is DirBranch. That's what I wrote.

Subdirs is tracked (or not tracked) for directory timestamp restore inside the root directory. The root directory is tracked for directory timestamp restore ...
What else to say here?

No offense, I may be wrong, but I get the feeling that you invented story with a root just to justify the name of the key. I suggest you judge sensibly. The subdirectories for commands like delete relate to the visible items (the current directory and its list). The option I offer is not tied to the root in any way. The concept of a "subdirectory", according to sound logic, can and should be associated with current objects, and not those that we may not observe (drive root in this case). This is an acceptable logic. Or do you seriously believe that the author will implement some kind of monitoring from the root? I'll bet you that it won't happen. All he can do is change the timestamps of the high-level folders, but only this theme was created for the reverse task — restoring the date, which is not required for folders above the parent, since their default dates don't change anyway.

[andry81]

Or do you seriously believe that the author will implement some kind of monitoring from the root?

The author have to monitor the directories to restore the timestamp *AFTER* the OS change it (after TC delete/move/etc), but *BEFORE* any other change from outside, for example, by a script, otherwise it can be miswritten.

[Fla$her]

The author doesn't need it. It is enough for him to receive a message about the end of the deletion operation to return the date that was before the operation began. When deleting multiple files, the date changes many times. There is no need to do this with each such intermediate date change. If I knew how to get such a message, I would have done so in the script.
While the deletion operation is in progress, a flag may appear in the allocated memory, which is responsible for ignoring the date restoration in case the first new object is created in the folder.