Total Commander

Hi!

On synchronizing directories, I sometimes have the same files on both sides but with different timestamps. I then use the "Copy file properties" command from the context menu instead of copying the whole file.

There's just a little problem: If the target file has the read-only attribute, copying the timestamp fails. However, this isn't reported in any way. You just see that the files still have different timestamps.

It would be nice to get an error message in this case. Maybe it would be useful to make a dialog with an option/button to copy the properties anyway (just the same as when copying files).

I've checked the behavior with TC 7.57a and TC 8.0 Beta 23 (32-bit and 64-bit).

Greetings
Gerby

I would have to temporarily remove the read only attribute, set the timestamp, and set the attribute back. Do you think that this would be a good idea, or should the read only attribute be respected?

I would show a dialog, just like for copying files.
Screenshot of Read-Only dialog

The question in case of filestamp copying would then be something like "Do you want to copy the timestamp anyway?". Because the dialog refers to the read-only attribute, I wouldn't see a problem switching the read-only flag off in order to fulfill the operation. Unlike the file copying, it would be good to switch the read-only flag back on again afterwards, as you suggested it.

There's another situation where the described symptoms occur: if the current user doesn't have write rights for the destination file/directory.

Spontaneously I cannot say, if it would make sense to adapt the full problem handling from file copying to attribute copying (i.e. dialog with several options including repeating with admin rights etc. pp.).

@ghisler(Author)

There is another problem in the situation described above.

When we select "Copy these file properties": "Timestamp (date+time)" and also "File attributes", then the attributes are being copied (and for example read-only attribute is being cleared in the destination file), but the timestamp is NOT being set.

Best regards!

Some file systems prevent the writing of the timestamp when the target file has the read only attribute set. Currently TC doesn't copy the timestamp in this case.

However, when a read-only attribute is being cleared (due to copying file properties), the timestamp should also be copied (attributes should be overwritten before the timestamp). Similarly, when read-only attribute is being set, the timestamp should also be copied (but now attributes should be overwritten after the timestamp).

There is a small inconsistency:
Removing the read-only attribute temporarily, setting the timestamp, and setting the attributes back:
a) is (as I suppose) implemented in the "Files -> Change Attributes" dialog,
b) is NOT implemented in the "Synchronize Dirs" dialog.

Maybe the best solution would be adding a TCMD configuration option like "overwrite properties of read-only files in Synchronize Dirs". Or adding a sub-option to "Copy these file properties" dialog, like "overwrite properties of read-only files".

Regards!

ghisler(Author) wrote:I would have to temporarily remove the read only attribute, set the timestamp, and set the attribute back. Do you think that this would be a good idea, or should the read only attribute be respected?

Please recall this thread for setting file properties through ContentSetValue of WDX plugins. In this case read-only attribute is not respected. Please keep it consistent.

It's not the same situation: In this thread, it's about copying attributes, while in the other it's about explicitly setting them. For comparison, you also get a warning when copying files and the target is read only...

Hi!

I just have fallen over that issue again and I'm curious if you, Christian, have already plans in the drawer to handle it in some way. I'm using TC 8.01RC4 x64 right now.

I think a straight-forward solution could be a simple message indicating that the attributes of one or several destination file(s) could not be changed (due to read-only flag or read-only rights). This would at least prevent the user from scratching his head.

Greetings
Gerby

I will check how complex it would be to add it. I don't want to add many new features to 8.01 because it also means new bugs.

No rush. I wouldn't mind to find a solution in a later version, as I understand 8.01 to be a bug-fixing-only release, too.