Opened 10 years ago

Closed 6 years ago

#3910 closed bug (no change required)

building with emulated attributes can cause directories to have incorrect mime type.

Reported by: jonas.kirilla Owned by: bonefish
Priority: normal Milestone: R1
Component: Build System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #8905
Has a Patch: no Platform: All

Description

Booting a Haiku CD built using the haiku-cd jam target, two of the Deskbar entries show the application icon even though they´re folders. Catattr BEOS:TYPE indeed shows an application mime type on all 4 folders in Deskbar. (Folders Applications and Preferences have their icons swapped for overlayed ones, otherwise they would show with the three-blocks executable icon too.)

IIRC /boot/home/config/be and /boot/home/config/boot too have the application mime type and opening Filetypes on them reveals that one of these (dont recall which) has some resource attributes belonging to some UHCI binary.

Change History (13)

comment:1 by stippi, 10 years ago

If you don't have xattr support enabled on your Linux system, in case you use Linux, you should see a generated/attributes folder. What happens if you delete that folder and do a clean build? Can you still reproduce the problem then?

comment:2 by jonas.kirilla, 10 years ago

Yes, I´m using Linux but without xattr support.

I have remove generated/attributes and I am currently rebuilding.

It seems that my _HAIKU entries were wrongly populated. Mounting a haiku-cd.iso image as plain iso9660 revealed that the _HAIKU entries of directories actually had a be-executable type and something about Developer Build in them. The few other _HAIKU entries I looked at seem to be correct, e.g. those of mime type and those of true applications.

comment:3 by anevilyak, 10 years ago

The reason he asked that is because issues like that have been seen in the past with the attribute emulation on non-xattr volumes. I used to get this bug every now and then with regular builds until I switched over to using xattr.

comment:4 by jonas.kirilla, 10 years ago

I´ve never seen this issue with the disk target.

What I think was a clean haiku-cd build showed the same error. But I did a disk build in between jam clean and the haiku-cd build. Will try again doing a straight "sudo rm -rf generated/attributes; sudo jam clean; sudo jam -q haiku-cd;" and see how that goes.

comment:5 by jonas.kirilla, 10 years ago

A clean build showed the same thing. Will try a GCC4 build tomorrow.

comment:6 by jonas.kirilla, 10 years ago

Looking at the build system (which I can´t say I have a decent grasp of) I got the impression that attributes get built from resources and that these are built/processed somehow.

Maybe there are some kind of resource defaults (in some Jam rule or action?) that cater to executables, or those things get added somewhere along the way.

Or maybe data from some previous resources/attributes creation spills over into the next.

The numbers used in the generated/attributes folder, where do they come from?

comment:7 by jonas.kirilla, 10 years ago

Component: File SystemsBuild System
Owner: changed from axeld to bonefish

A clean x86/gcc4 haiku-cd build shows the same thing. Random folders with a BEOS:TYPE attribute of the executable mime type. "svn status" shows nothing but a few of my uncommitted changes to source and header files - no changes to any files related to jam or the buildtools.

Changing component. Looking at the _HAIKU folders its plain to see that its not the attribute overlay that misinterprets anything, so I think its safe to blame the build system.

The folders are likely not random. I will enumerate them shortly.

comment:8 by jonas.kirilla, 10 years ago

This could be a comprehensive list of the folders that get _HAIKU entries:

./home/Desktop
./home/config/be
./home/config
./home/config/be/Applications
./home/config/be/Demos
./home/config/be/Desktop Applets
./home/config/be/Preferences
./home/config/settings/Mail/ProviderInfo
./home/config/settings/Mail
./home/config/settings/printers/Preview
./home/config/settings/printers/Save as PDF
./system/apps
./system/bin
./system
./system/data
./system/demos
./system/etc
./system/lib
./system/preferences
./system/servers
./system/add-ons/kernel/drivers/dev/bus
./system/add-ons/kernel/drivers/dev/disk
./system/add-ons/kernel/drivers/dev/dvb
./system/add-ons/kernel/drivers/dev/graphics
./system/add-ons/kernel/drivers/dev/input
./system/add-ons/kernel/drivers/dev/misc
./system/add-ons/kernel/drivers/dev/net
./system/add-ons/kernel/drivers/dev/disk/floppy
./system/add-ons/kernel/drivers/dev/disk/usb
./system/add-ons/kernel/drivers/dev/disk/virtual
./system/data/artwork
./system/data/sounds
./system/data/locale/languages
./system/etc/word_dictionary

FWIW: in /boot/system ./add-ons and ./fonts don´t get _HAIKU entries.

It looks like "word_dictionary" gets the resources of the kernel.

Am I the only one seeing this? ´:)

comment:9 by diver, 10 years ago

Same here with jam @alpha-cd.
Also with jam @alpha-vmware I started seeing recently something that could be related to this bug:
/boot/common now have text/plain mime type.

comment:10 by mmadia, 10 years ago

Summary: Something wrong in attribute overlay or in the build system populating haiku-cdbuilding with emulated attributes can cause directories to have incorrect mime type.

To note, building Haiku on filesystems that rely upon emulating attributes is not recommended. Recommended filesystems include: BFS, UFS2, ReiserFS. See http://www.haiku-os.org/guides/building/configure/use-xattr for more info.

comment:11 by diver, 10 years ago

Version: R1/pre-alpha1R1/Development

Still here in hrev35863.

comment:12 by diver, 7 years ago

Blocking: 8905 added

(In #8905) Most likely a dupe of #3910.

comment:13 by bonefish, 6 years ago

Resolution: no change required
Status: newclosed

Closing as "won't fix". By design the generic attribute emulation cannot be 100% safe, since the inode IDs of files can actually change (while those being stable is the assumption the design is based on). I think in the meantime pretty much everything possible to improve the situation has been done (e.g. removing stuff only via rm_attrs). Last time I tried the image resulting from a clean build looked good.

With the introduction of --use-xattr-ref there should rarely be any reason to use the generic attribute emulation anyway.

Note: See TracTickets for help on using tickets.