Opened 7 years ago

Closed 7 years ago

#8858 closed bug (fixed)

[mimeset] silently fails on symlinks

Reported by: diver Owned by: anevilyak
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This is hrev44503.

mimeset -f /boot/home/Welcome

doesn't identify Welcome link on the Desktop and doesn't print anything. Identify/Force identify from Tracker doesn't work either.

Change History (9)

comment:1 Changed 7 years ago by anevilyak

Component: Kits/Storage KitServers/registrar
Status: newassigned

It turns out that it is actually succeeding ; at identifying the link itself. The registrar opens the supplied ref such that it's not followed if it's a link. As a consequence, the sniffer is only run on the link itself, which obviously just gets identified as a symlink. I'd propose that if the ref upon which a mime update is requested is a link, then we also update info for its target, since that's the more likely behavior anticipated by the user. Will leave the ticket open for now in case anyone objects/has an alternative suggestion, otherwise I have a trivial patch which would handle the above change.

comment:2 Changed 7 years ago by leavengood

I think the proposed fix makes sense. I can't imagine there ever being a time when the user really wants to make sure something is a symlink by identifying it. And is a symlink ever not already identified as a symlink?

comment:3 Changed 7 years ago by bonefish

The update_mime_info() and create_app_meta_mime() (and mimeset) behavior matches BeOS'. I also think it makes sense, since those functions have a recursive mode and you definitely don't want to follow symlinks in that mode, since that could result in infinite recursion or wild jumps.

I don't think the behavior of the functions or mimeset should change. If you want an initial symlink to be resolved, it is rather simple to do that before calling the function/tool, using the BeAPI (e.g. BEntry) or in the shell readlink.

I agree that Tracker's "Identify" feature should be more intelligent, though.

comment:4 Changed 7 years ago by anevilyak

Component: Servers/registrarApplications/Tracker
Status: assignedin-progress

Understood, will tweak Tracker then.

comment:5 Changed 7 years ago by diver

Unfortunately this won't help mime_update.sh script to resolve Welcome and User Guide symlinks.

comment:6 Changed 7 years ago by anevilyak

That could alternatively be fixed by adding:

mimeset       -f "$SYSTEM/bin"

To the list of things that script touches.

comment:7 Changed 7 years ago by diver

Yes, but this will take even more time on the first boot from ISO.

comment:8 Changed 7 years ago by bonefish

Please note that the whole mime_update.sh thing is a temporary work-around (since the build system should do that already). So I wouldn't try to optimize all that much. Instead of adding the whole system bin folder only the two concerned files could be processed, though.

comment:9 Changed 7 years ago by anevilyak

Resolution: fixed
Status: in-progressclosed

Fixed in hrev44513.

Note: See TracTickets for help on using tickets.