Trouble copy files in builds after June 2nd


I have a shell script that builds, copies, and creates the archive for a program I’m developing for Haiku. In builds after June 2nd, files that the script copies lose their mime types (I think) and are basically unusable. For example, an .html file that can be opened in BeZilla just by double clicking, is opened in StyledEdit after the script copies it to a new folder. Application files that are copied, no longer run properly, they seem to be corrupted.

I haven’t changed anything in the script for at least 2 months, so this wasn’t due to any changes I’ve made. I’ve tried this on 2 machines and 1 VM and I get the same behavior and only on builds after about June 2nd.

Is this a known issue? Anything I can do to help isolate the problem for someone to fix?


OK, I finally got some time to debug this issue today.

The problem is caused by a bug introduced by ticket #4015 (r31000), fixed by axeld. A change was made to cp in order to copy empty attributes in files. The fix has a bug in it however.

Line 166 in haiku/trunk/src/bin/coreutils/src/copy.c currently reads:

 if (bytesWritten != bytesRead || bytesRead == 0)

It should read:

 if (bytesWritten == bytesRead || bytesRead == 0)

The way it currently is, it continues through a loop one more time which writes 0 bytes to the attribute which erases the bits written the first time through.

The bug can be reproduced simply by copying any file with attributes from the terminal using cp. You’ll find the copied file has all the attributes of the original file, but they are empty. My privately built cp with the change fixes the problem.

I’m actually shocked no one else has hit this.

Can someone please file a ticket to get this fixed? I do not currently have access to file tickets.


I figured out the ticket system and have received access now to file new tickets. I filed ticket #4048 on this bug.