Haiku corrupts vlc binary

[kaoutsis]

• run haiku (tested with real hardware, hrev21848)
• unzip from haiku the vlc zip package:

unzip vlc-0.8.6c-BeOS.zip

• cd vlc-0.8.6c
• ./vlc

works amazingly well listen a internet radio station, or watch a internet tv station.

• close the app
• reboot
• after reboot rerun the vlc binary

you should get: sh: ./vlc: cannot execute binary file

*finally i mounted the haiku partition and try to run the binary from hrev5: the same result sh: ./vlc: cannot execute binary file

[axeld]

Just curious about "reboot" - are you shutting down Haiku correctly? Because only then the caches are written back.

[kaoutsis]

Replying to axeld:

Just curious about "reboot" - are you shutting down Haiku correctly? Because only then the caches are written back.

Yes. i am shutting down haiku correctly; After all that is the point:)

[aldeck]

Replying to kaoutsis: I may be wrong but i always run 'sync' after any file op, if i were you i would do a sync after unziping :)

[stippi]

It's still a bug though if multiple file ops and a sync produces different results than a sync after each op. I have seen this bug too I think. We hoped that it would have disappeared with all the file cache and vm fixes recently.

[kaoutsis]

Replying to aldeck:

Replying to kaoutsis: I may be wrong but i always run 'sync' after any file op, if i were you i would do a sync after unziping :)

followed your suggestion: i ran sync after unzipping; then the vlc runs fine and reruns fine after reboot. The strange thing for me is that if i run sync not immediately after unzipping, but i run vlc first, close the app and then run sync and reboot, the problem appears again.

[tangobravo]

I've noticed it too - and it seems from 1399 it applies generally to all executables.

<wild speculation>Does something in the first-execute code path assume the file is actually on the disk instead of just in the cache?</wild speculation>

[bbjimmy]

The new file is corrupted if it is executed before a Restart. If it is not executed until after a Restart the file is not corrupted and can be executed any number of times.

( simple quick test ... ​http://216.110.210.251/fatelk/TextSaver.zip unzip copy TextSaver /boot/home/config/add-ons/Screen Savers/ execute the screensaver THEN reboot.

now the TextSaver file in /boot/home/config/add-ons/Screen Savers/ does not match the file in the TextSaver folder.

re-copy the file and Restart THEN execute the file ... now the system can re-boot and the file is not corrupted.

NOTE: the corruption is not limited to screensavers, this is just a quick test case)

looks like something with a combination of copying the file and then executing it.

[axeld]

I've found the problem: when executing the application, some pages are moved from the modified list to the active list - therefore, when the cache is written back, those pages are simply not written. On next boot, those pages are just empty (or just contain garbage, since BFS currently does not clear unused space).

[axeld]

Fixed in hrev21971.

[kaoutsis]

Replying to axeld:

Fixed in hrev21971.

thanks!

[stippi]

Wow, whenever I think, "dude, that's gonna be a tough one", here come Axel or Ingo with a fix already! Great that this one got nailed! It was causing me quite a feeling of uncertainty... :-)