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

Here you can propose new features, make suggestions etc.

Moderators: white, Hacker, petermad, Stefan2

andry81
Member
Member
Posts: 104
Joined: 2018-11-22, 19:17 UTC

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

Post by *andry81 »

Fla$her wrote: 2024-05-15, 13:30 UTC 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
Power Member
Power Member
Posts: 2379
Joined: 2020-01-18, 04:03 UTC

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

Post by *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.
andry81 wrote: 2024-05-15, 14:42 UTC So the `_RecurseSubdirs`
Maybe you're confusing 'Subdirs' with 'High-level dirs'?
Overquoting is evil! 👎
andry81
Member
Member
Posts: 104
Joined: 2018-11-22, 19:17 UTC

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

Post by *andry81 »

Fla$her wrote: 2024-05-15, 14:52 UTC 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.
Fla$her wrote: 2024-05-15, 14:52 UTC 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.
Fla$her wrote: 2024-05-15, 14:52 UTC 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
Power Member
Power Member
Posts: 2379
Joined: 2020-01-18, 04:03 UTC

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

Post by *Fla$her »

andry81 wrote: 2024-05-15, 17:32 UTC 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.
andry81 wrote: 2024-05-15, 17:32 UTC 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.
Overquoting is evil! 👎
andry81
Member
Member
Posts: 104
Joined: 2018-11-22, 19:17 UTC

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

Post by *andry81 »

Fla$her wrote: 2024-05-15, 20:47 UTC 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
Power Member
Power Member
Posts: 2379
Joined: 2020-01-18, 04:03 UTC

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

Post by *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.
Overquoting is evil! 👎
Post Reply