Inconsistent setting of archive attribute

[Henning]

If a file is being copied from one local directory to another one during a Folder Compare session, the new file will have its archive attribute set, irrespective of whether the archive attribute was set on the original file.

If the file is being copied from an FTP server instead, the archive attribute will not be set on the local file, which is a bit irritating.

Beyond Compare 2 was more consistent in that files that were created in a Folder Compare session always got their archive attribute set, irrespective of their origin.

Is there a configuration setting to change the behaviour of BC3 ?

Thanks,
Henning

[Aaron]

Hello Henning,

There is not an option to change this behavior in BC3. Our new FTP library treats them differently by default.

Which behavior would you expect when performing the copy on a file with the bit set, or with the bit unset?
What if the file is in an archive/zip?

[Henning]

Hi Aaron,

I would expect a behaviour similar to the one shown by BC2.
IMHO it actually should not matter whether the source file has the archive bit set or unset and whether it is located on a local drive or on an FTP server. In order to tag the copy as being either a new or updated file, the archive bit should be set in any case.

BTW, I may have misunderstood your comment, but do files on an FTP server really have something like an archive attribute associated with them? I thought that those attributes shown in the Folder Compare view are just related to file permissions.

Thanks,
Henning

[Zoë]

The next release will have this fixed so the archive bit is set correctly.

FTP servers running on MS Windows can return the original DOS attributes, but most don't and send back simulated Unix permissions instead.