Talk:Comparison of file synchronization software: Difference between revisions

Revision as of 19:51, 3 November 2021

Revision as of 10:17, 31 October 2022

Line 151:

Thanks for considering this.

: There are already too many columns in the tables, although this could be solved by removing the extremely sparsely populated and questionably useful ones (application and protocol layer; wow! 4 programs use TCP? Jerkoff motion initiated!), and probably the "programming language" column, since this only matters if the language itself is required to use the program. I have no idea what software you were using, but most software assumes the modification times are correct and overwrites the older (or newer even) file unless you tell it not to. Robocopy works like that and has been included with Windows forever. There's also the archive bit. <br/>

: You never mentioned what OS you're using, so I'm just assuming "the most common one". <br/>

: Any backup software that ignores modification dates and relies on file size should be considered fundamentally broken, anyway. Aside from your use case, which isn't how that normally works in the case of MP3, anyway (I think it's just part of the FLAC format so doesn't really count as padding); try adding album metadata to a bunch of MP3s that didn't have any or use different formats of tag data and it'll immediately start increasing file sizes, I'm pretty sure the tags are just fixed-size data structures so once any of the information is there so is all of the space for it... you can't have arbitrarily long artist / album names in normal MP3 metadata; you can have sparse files which are pre-allocated to some set size (possibly gigantic) but only occupy disk space for non-zero portions of the data, and files on NTFS can have alternate streams which can be used for practically anything and don't occupy space as far as the information shown to the user and badly written software are concerned. It's not hard to make a 1kb text file that has a bluray ISO attached as Movie.txt:movie:$DATA or whatever even if doing so is kinda pointless. Anything going on size alone would fail to backup either of those, and those things contain ''important'' data.<br/>

: Assuming that programmers inserted padding in any file format because they had a single clue how the OS needed to handle data appended to a file (or OS resources when talking about extra data tacked onto music files) is vastly overestimating programmers. It's usually better to assume that their godawfully written spaghetti C code was initially intended to support strings of any size for the fields of the tag but they had no idea how or when to allocate and free memory correctly and kept OOM or segfaulting with their intial version. If the person who came up with the tag type knew what ''they'' were doing, they probably thought about it for 5 minutes and realized that the 30 open source media players that would need to read this information from ''their'' godawfully written spaghetti C players would probably end up creating all kinds of vulnerabilities if they were forced to deal with variable length strings. <br/>

: Without looking I'd assume that every single piece of software in this table does what you're asking, and you were just very slightly burned by using something completely horrible that you failed to mention the name of. [[User:A Shortfall Of Gravitas|A Shortfall Of Gravitas]] ([[User talk:A Shortfall Of Gravitas|talk]]) 10:16, 31 October 2022 (UTC)

== Missing some vital info -- Method and Scenario ==