[TC10.51] Issue: File change date is less than file create date

[andry81]

I don't know is that known or not, but TC does not highlight or mark new files if were created with the issue. This is a bit inconvenient because the user won't see new files.

This can be achieved with the rsync 3.x utility while download new files with that rsync command line:

-ravz --chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r

I use it to download a project with all svn repositories from the sourceforge.net.
The generic command looks like this:

rsync <flags> svn.code.sf.net::p/<project-name> .

If open downloaded server side svn repository directory then, there is would be a path:

<project-name>/<repo-name>/db/revs/0

containing new files related to respective commit revisions. So, the new files will not be highlighted with the TC as new files because of the issue.

Is there a chance to fix that?

[Dalai]

What is there to fix? You told rsync to archive the files (-a switch) and it's doing exactly that, synchronizing the file's timestamps. If you want to see the file's creation time, you can create a custom columns view and add [=tc.creationdate] and/or [=tc.creationtime] to it.

Not sure of rsync is able to synchronize all three file timestamps, but I doubt that it works across different operating systems.

Regards
Dalai

[Horst.Epp]

Moderators should move that out of bug reports

[andry81]

What is there to fix?

Highlight new files on the local side.

You told rsync to archive the files (-a switch) and it's doing exactly that, synchronizing the file's timestamps. If you want to see the file's creation time, you can create a custom columns view and add [=tc.creationdate] and/or [=tc.creationtime] to it.

Yes, because I downloading from the remote side and want the exact files tree. But because I already have the old tree, then I want to see what's new has downloaded on the local side.

Not sure of rsync is able to synchronize all three file timestamps, but I doubt that it works across different operating systems.

I didn't want that.

[Dalai]

Highlight new files on the local side.

What do you mean exactly? Are we talking about TC's Synchronize directories? If so, which aspect in particular? Single files that are on one side only, or do you mean files on both sides that only differ in their timestamps? If you're refering to the latter, then I'm wondering why a file with different content has the same timestamp (on the rsync server in this case).

Regards
Dalai

[andry81]

Highlight new files on the local side.

What do you mean exactly? Are we talking about TC's Synchronize directories? If so, which aspect in particular? Single files that are on one side only, or do you mean files on both sides that only differ in their timestamps? If you're refering to the latter, then I'm wondering why a file with different content has the same timestamp (on the rsync server in this case).

Ok, I have checked the application instance under different user and it is not enabled by default.

To reproduce:

1. Press `+` from the Numeric Tab to open `Expand selection` dialog
2. Click `Define...` button to open `Define selection`
3. Select `Advanced` tab and set `Not older than` checkboxed field to `1` - `day(s)`
4. Save as `Recently Used - 1 day`
5. Add selection rule to the colorizer and select the color: Configuration -> Display -> Color -> Define colors by file type...
6. Go create some empty file through the `Shift+F4` shortcut
7. Observe the highlighted foreground file name (red is by default)

To change highlightness:

1. Select file
2. Select Menu: Files -> Change attributes... -> Change date/time -> Date (select date before the current greater than 1 day and less the creation date)

To change colors:

Configuration -> Display -> Color -> Define colors by file type...

I have enabled that by default through a plugin.

[Dalai]

TC should apply the highlight colors when the directory is refreshed (e.g. via Ctrl+R).

Regards
Dalai

[andry81]

TC should apply the highlight colors when the directory is refreshed (e.g. via Ctrl+R).

It's not the case.

I think the function should be:

highlight_function(max(create_time, change_time), current_time)

Instead of:

highlight_function(change_time, current_time)

[Usher]

2andry81
Selection (as available from Mark menu, including Num+ hotkey) is NEVER extended automatically. That's why 2Dalai has asked about Synchronize option.

Selection is kept unchanged as long as possible, even after directory refreshing. However, selection may be narrowed (made more limited) when using quick search with filtering enabled (by Ctrl+S).

If you want to get proper selection, you should make it when expected actions are finished, otherwise you may get unpredictable results. Imagine that you want to delete some selected files (f.e. using MS*.* wildcard)...

[andry81]

2andry81
Selection (as available from Mark menu, including Num+ hotkey) is NEVER extended automatically. That's why 2Dalai has asked about Synchronize option.

Selection is kept unchanged as long as possible, even after directory refreshing. However, selection may be narrowed (made more limited) when using quick search with filtering enabled (by Ctrl+S).

If you want to get proper selection, you should make it when expected actions are finished, otherwise you may get unpredictable results. Imagine that you want to delete some selected files (f.e. using MS*.* wildcard)...

Not sure what you talking about. How is that related to the issue?

[Dalai]

Can you give an example on what exactly happens when you download those files and what happens instead, and why you think to expect something else? Maybe create a screenshot if necessary.

Also please use correct terminology. To me it's still not fully clear what exactly we're talking about. Is is about coloring files by filetype (by date in this case)? Is it about selecting/marking files? Something else entirely?

The steps above (viewtopic.php?p=420753#p420753) work fine for me. Are you sure the coloring isn't overridden by another rule?

[EDIT]
Please also specify the TC version, TC bitness/architecture, Windows version, and if you're using dark mode in TC.
[/EDIT]

Regards
Dalai

[andry81]

Can you give an example on what exactly happens when you download those files and what happens instead, and why you think to expect something else? Maybe create a screenshot if necessary.

You don't need to download anything to reproduce the issue.

Also please use correct terminology. To me it's still not fully clear what exactly we're talking about. Is is about coloring files by filetype (by date in this case)? Is it about selecting/marking files? Something else entirely?

The application does use a file change date instead of a file creation date to colorize a file by the `Recently Used - 1 day` selection rule. Which means the recently created file creation date is closer to the current date than the file change date, but nevertheless the change date is used to colorize the file. But because the file change date is less than the file creation date and away more than 1 day from the current date then, is not properly colorized as "recently used in 1 day". What's the point.

The steps above (viewtopic.php?p=420753#p420753) work fine for me. Are you sure the coloring isn't overridden by another rule?

You didn't change the file change date and didn't set it to a past date than the creation date.

[EDIT]
Please also specify the TC version, TC bitness/architecture, Windows version, and if you're using dark mode in TC.
[/EDIT]

TC 10.51. Windows 7 x64. Dark mode enable. But I've tested both modes and I don't think it is related to the issue somehow.

[UPDATE]
Ok, I've found the missed step:

• Add selection rule to the colorizer and select the color: Configuration -> Display -> Color -> Define colors by file type...

[/UPDATE]

[Dalai]

You don't need to download anything to reproduce the issue.

It's not about that. I asked you to tell us what you see and what you expect, that's all.

The application does use a file change date instead of a file creation date to colorize a file by the `Recently Used - 1 day` selection rule. Which means the recently created file creation date is closer to the current date than the file change date, but nevertheless the change date is used to colorize the file. But because the file change date is less than the file creation date and away more than 1 day from the current date then, is not properly colorized as "recently used in 1 day". What's the point.

I think I know where the problem lies. You expect TC to color files based on their creation date, but it does so based on the modification date.

You didn't change the file change date and didn't set it to a past date than the creation date.

Of course I did. It's just that I expect something different to happen and TC's behavior lines up with that expectation.

To summarize:

1. TC's "Not older than" finds files based on their modification date
2. You expect TC's "Not older than" to find files based on their creation date instead

Did I get that right?

What happens when copying a file to a directory where a file with the same name doesn't exist yet? Its creation date is set to the current time, but its modification date stays exactly the same. It's a different story with CopyAllTimes=1, but that's not a default setting.

Now let's assume for a moment that TC would base its search option "Not older than" on the creation date. What would happen to such files? The copy is found (and colored accordingly), but the original file isn't - despite TC showing the exact same date and time for both of them in the default view "Full"!

To meet your expectations you need some kind of plugin, like Age.

[EDIT]
Changed the view "Long" to "Full".
[/EDIT]

Regards
Dalai

[AntonyD]

If you remember for a moment that the date of file creation can not be later than the date of its modification, then in theory the behavior can be adjusted trivially: the option "not older by" X units should compare BOTH time parameters. Starting from the creation date. If the "now" date is greater than the Creation Date by X units, then this option worked. If not, then compare the Modification Date - if the date "now" is greater than M.D. by X units, then the option again worked. That's All.

[andry81]

To summarize:

1. TC's "Not older than" finds files based on their modification date
2. You expect TC's "Not older than" to find files based on their creation date instead

Did I get that right?

Yes

Now let's assume for a moment that TC would base its search option "Not older than" on the creation date. What would happen to such files? The copy is found (and colored accordingly), but the original file isn't - despite TC showing the exact same date and time for both of them in the default view "Long"!

Why? Original file will be colored accordingly its creation date too. If it's old enough then, it won't be highlighted and this is expected. Don't see here nothing strange. What the `default view "Long"` is?

To meet your expectations you need some kind of plugin, like Age.

Age can be used to search for files where the file age is roughly known.

This is a kind of different functionality and is not enabled by default.

Why just not add a combobox into `Find Files -> Advanced`:

Code: Select all

[x] Not older than: [1              ][^v] [days(s)        v] [ Max of Creation/Modification date  v]
                                                             | Creation date                       |
                                                             | Modification date                   |
                                                             ---------------------------------------

It will solve all the cases.

Additionally, you could run under Virtual Machine where the current time is shifted to the past. And would be easy to just go and change the switch for already existed rule.