Skyline: Add MultiFileLoader.Dispose() to dispose its QueWorker…

[brendanx67]

… and call it from ChromatogramManager.Dispose()

• Remove desktop.ini file from ExportMethodDialogTest.zip to improve the folder deletion experience for test results folders

[chambm]

How does removing desktop.ini improve folder deletion? Avoids an extra confirmation dialog?

Of course it shouldn't have been in there in the first place, but just keep in mind that updating the zip file (probably) increases the repository size by the zip file size because git (probably) can't do much delta compression between zips.

I say probably because 7zip was able to zip up the before and after ExportMethodDialogTest.zip zips to the same size as 1 zip with LZMA2 algorithm, but the zip/deflate algorithm was double the size. A brief search in git docs doesn't reveal any special compression modes for binary files.

NB: it's too late to reverse this without GC'ing the repository since it's already been pushed, but it's worth keeping in mind for future zip file updates. (Repository size is still on my mind from considering the effect of Resources.resx changes on repository size). This is why I stopped using tarballs for changes to vendor test data and BiblioSpec test data.

[nickshulman]

keep in mind that updating the zip file (probably) increases
Point taken.

How does removing desktop.ini improve folder deletion? Avoids an extra confirmation dialog?

This pull request originally had modified "ExportMethodDialogTest.zip", which I had to revert when I merged from master.
I felt I ought to apply the same change that Brendan had before after merging, which, unfortunately, resulted in an extra version of that file being added to the history.
Yes, I believe removing desktop.ini prevents Windows Explorer from warning that you are deleting a system file.

I have long been thinking that we should modify "ExtensionTestContext.ExtractTestFiles" so that, if it notices that the .zip path is actually a directory name, it just copies the files out of there instead of extracting a zip. This would enable us to decide case by case whether it's better to check in a single .zip file or the contents of an exploded zip.

My guess is that two nearly identical binary files will probably get compressed well by git when everything is packed together, but I am not sure. I read somewhere that git looks for files which have identical filenames, and compresses those in the same block, so that if there is a lot of data shared between them the end result is smaller. However, I don't know whether that would actually be effective on two 6MB files, and I'm not even sure that this happens for binary files-- maybe only text.
In theory, if these two .zip files were in a single .tar file, and that .tar file was compressed, the resulting compressed file would be about the same size as what you would get if you compressed a single .zip file. However, with some of these compression algorithms, although they are good at finding duplicated data, they might not be able to remember it long enough to detect a duplications that a separated by 6MB of data.

[chambm]

In theory, if these two .zip files were in a single .tar file, and that .tar file was compressed, the resulting compressed file would be about the same size as what you would get if you compressed a single .zip file. However, with some of these compression algorithms, although they are good at finding duplicated data, they might not be able to remember it long enough to detect a duplications that a separated by 6MB of data.

Easy enough to test. The uncompressed tar is of course 12MB. Compressing that with either gzip or bzip2 on max compression results in a change less than 100KB (slight growth in bzip2's case, slight shrinkage for gzip). Long live LZMA2! Unfortunately git doesn't use it. :)

[brendanx67]

/rebase