Opened 15 years ago
Closed 10 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 | |
| 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 , 15 years ago
comment:2 by , 15 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 , 15 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 , 15 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:6 by , 15 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 , 15 years ago
| Component: | File Systems → Build System |
|---|---|
| Owner: | changed from to |
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 , 15 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 , 15 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 , 15 years ago
| Summary: | Something wrong in attribute overlay or in the build system populating haiku-cd → building 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:13 by , 10 years ago
| Resolution: | → no change required |
|---|---|
| Status: | new → closed |
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.
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?