remove system file when testing

[glensc]

solves #3 using solution "1"

[glensc]

can't test osx part because travis macos infrastructure is down:
https://www.traviscistatus.com/
https://www.traviscistatus.com/incidents/4qylrqvy50gy

[glensc]

https://travis-ci.org/file/file-tests/jobs/279692965

@thomasjfox do you know how the test data is modified?

on OSX an x.iso is detected differently:

FAIL db/iso/x.iso
Expected :DOS/MBR boot sector; partition 1 : ID=0x17, active, start-CHS (0x0,0,1), end-CHS (0x2c7,63,32), startsector 0, 1458176 sectors
Got      :ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'testday-20110324' (bootable)
Expected :application/octet-stream; charset=binary
Got      :application/x-iso9660-image; charset=binary

https://travis-ci.org/file/file-tests/jobs/279692965#L643

[thomasjfox]

On Dienstag, 26. September 2017 17:44:14 CEST Elan Ruusamäe wrote: https://travis-ci.org/file/file-tests/jobs/279692965 @thomasjfox do you know how the test data is modified? on OSX an `x.iso` is detected differently: ``` FAIL db/iso/x.iso Expected :DOS/MBR boot sector; partition 1 : ID=0x17, active, start-CHS (0x0,0,1), end-CHS (0x2c7,63,32), startsector 0, 1458176 sectors Got :ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'testday-20110324' (bootable) Expected :application/octet-stream; charset=binary Got :application/x-iso9660-image; charset=binary ```

the output looks a bit odd to me. I've checked the input file and it should indeed be a ISO 9660 filesystem image. file-5.29 on my Fedora 25 workstation gives the correct result: $ file ../file-tests/db/iso/x.iso ../file-tests/db/iso/x.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'testday-20110324' (bootable) $ file --mime-type ../file-tests/db/iso/x.iso ../file-tests/db/iso/x.iso: application/x-iso9660-image file-5.28 compiled from source gives: $ src/file --mime-type -m magic/magic.mgc ../file-tests/db/iso/x.iso ../file-tests/db/iso/x.iso: application/x-iso9660-image file-5.29 compiled from source gives: $ src/file --mime-type -m magic/magic.mgc ../file-tests/db/iso/x.iso ../file-tests/db/iso/x.iso: application/octet-stream So it looks like a regression to me? I've you agree we should contact Christos since the file mailinglist is probably still down. Cheers, Thomas

[glensc]

but linux build succeeds on the same build:

• https://travis-ci.org/file/file-tests/builds/279692963
• linux: https://travis-ci.org/file/file-tests/jobs/279692964
• osx: https://travis-ci.org/file/file-tests/jobs/279692965

and i don't understand how the "diff" is made, as i read from readme, the .pickle files should be created from previous file release, but travis job currently present doesn't do that. it just runs diff of current codebase. i would suspect first cache from previous runs, but there's nothing configured to be cached between travis builds...

[thomasjfox]

On Tuesday, 26 September 2017 23:59:53 CEST Elan Ruusamäe wrote: but linux build succeeds on the same build: - https://travis-ci.org/file/file-tests/builds/279692963 - linux: https://travis-ci.org/file/file-tests/jobs/279692964 - osx: https://travis-ci.org/file/file-tests/jobs/279692965 and i don't understand how the "diff" is made, as i read from readme, the .pickle files should be created from previous file release, but travis job currently present doesn't do that. it just runs diff of current codebase. i would suspect first cache from previous runs, but there's nothing configured to be cached between travis builds...

I think you are right, the comparison to the previous DB seems not to be implemented. I've checked the git history of .travis.yml and it was like that since the initial commit. Which brings us to the point how the comparison should be done. In my local file-tests repo, we have a branch that contains the .pickle files since the last file package upgrade in our distribution. Committing the .pickle files to git won't work properly for other file-tests users, so we should save those .pickle files for Travis only. Would storing the .pickle files in a "Travis cache" work? If the file(1) output changes in a wanted way, we would manually clear the existing cache and it would rebuild itself with the new output. This still doesn't explain why OSX behaves differently though.