Ignore File Size

[adzlaw]

It would be great if there was an ignore filesize option similar to ignore timestamp.
For various reasons I don't want to have to encode the date/timestamp. I also don't want to avoid storing a cache of the listings ... simply ignore filesize. I can work around this by various convoluted means... but it would be easiest if I could ignore filesize and rely on verify on initial copy. If this could be implemented it would be great.

[tobias]

Hello,
can you explain the use case some more?

Files that have a different size are different and need to be copied / updated. So the size really cannot be ignored.

However, if you never want to update or replace files, you can choose the following checkmark under
Files->More:
X Never Replace Any Files

[adzlaw]

Hi Tobias,

In my case the problem with : never update or replace files is that I would like to update on date changes but not size changes.

One scenario of mine involved uploading an XML based file to a WebDav which changed the size as the encoding was changed from one encoding to another on upload. I could control the date by changing the date on upload but not the size. Also I did not want to encode the file date/size into the file name for various reasons. With one particular XML database I couldn't control the endpoint when informing of the file size.

People may wish to ignore size for the same reasons as they wish to ignore the date.

1) Another Actual Scenario

I presently have another complicated setup where I process EML files (and attachments - docx, etc) to PDF, PNG, XML, SVG etc. My feeling is ... can I simplify this and get rid of encoded dates/sizes all together.

The first realtime copy FFFF67EC6FD144EFB226F570B9692D5D.eml -> Folder 1: FFFF67EC6FD144EFB226F570B9692D5D.eml.d20150819-u065155.pdf.s2260949.zip ... on the OS at some date.

A trigger on the OS sees and processes the zip and writes a file2 to Folder2. As part of the process the modified date of File1 is updated to 20010101010101+8HRS to signify that the file has been modified. File2 is written as FFFF67EC6FD144EFB226F570B9692D5D.MAI.d20150811-u030014.eml.s2260949.d19991231-u170101.zip but its actual size changes. The 19991231-u170101 (20010101010101+8HRS) signifies that the file in Folder 2 is a processed file. If syncovery ran Folder1 -> Folder2 with a file not having been processed it would not have d19991231-u170101 bur rather another date e.g. .... \Images.d20160205-u094241.cdr.s6325832.d20160205-u094241.zip.s6294707.zip (I cannot process cdr files right now).

To make matters more complicated I chain this process a second time ... and result in file4

Anyway will all the date encoding getting from file 1 to file 4 without having to put file4 in a database and manage another database-> involves reading a chain of dates on the disk. I could simplify this and avoid reading a chain of dates on disk, if update on date changes but not size changes.

Also, it would simplify my process and I could remove the long encoded names which are becoming unwieldy. For example I cannot open them in notepad++

Notably I process a file with encoding
Folder3: FFFF67EC6FD144EFB226F570B9692D5D.eml.d20150819-u065155.pdf.s2260949.d19991231-u170101.zip.s6037391.d20000201-u180202.zip

I don't know why by there are only two size encoding (not three as there should possibly be). This is not relevant to me but might be to someone else.

3) A chain: file1 -> Golang/Redis WebDav -> XML WebDav with the file size changing at each step. I don't know dates on disk etc.

Aside I have used your PASCAL script post processing functionality. It works very well and I do love this feature. I am not presently using it as my processing takes a while so I add to a queue/channel as part of something else.

If you read this far --- many thanks I am a weirdo. Adam

[tobias]

Hello,
I think in general it's best to avoid multiple encodings in one file. Syncovery can't normally handle that very well, when it has to compare the left and right files.

The size is encoded into the filename only when the file is compressed. So compression adds the size plus the .zip or .sz extension, while versioning or Filename Encoding adds the timestamp.

Ideally try to find a protocol where the original timestamp can be preserved. Many WebDAV servers allow that, although there is no clear standard. It should also work fine with almost all FTP and SFTP servers.

For two-way syncs, it is already possible to determine what should happen with files that have the same timestamp but different sizes. Maybe I can extend that to one-way syncs as well.

[adzlaw]

Thanks Tobias

[tobias]

Hello,
the new version 9.12 now allows to ignore if only the size is different.
The option is on the "Comparison" tab sheet in the profile.