| Summary: | package/dropbear: symlink resolution incorrect | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | nospam+busybox |
| Component: | Other | Assignee: | Yann E. MORIN <yann.morin.1998> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | buildroot, yann.morin.1998 |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Fix dropbear when readling is busybox | ||
|
Description
nospam+busybox
2015-08-11 01:49:52 UTC
Hello, I've tried to reproduce the issue, but it just works for me here. But I've looked, and our default busybox configuration has CONFIG_FEATURE_READLINK_FOLLOW enabled. Did you customise your Busybox configuration? Regards, Yann E. MORIN. Yes, FEATURE_READLINK_FOLLOW is set. If it makes a difference, this is using the raspberrypi2_defconfig, with uClibc-ng. I investigated this further, and it may be a difference between Busybox/uClibc and coreutils/glibc. If the target of the symlink does not exist, in coreutils "readlink -f" will display as much as possible. In Busybox, "readlink -f" will result in an error, specifically ENOENT. Test case: ln -s /tmp/no_such_file /tmp/some_symlink On my Debian desktop: $ readlink /tmp/some_symlink /tmp/no_such_file $ readlink -f /tmp/some_symlink /tmp/no_such_file On my Raspberry Pi: # readlink /tmp/some_symlink /tmp/no_such_file # readlink -f /tmp/some_symlink # touch /tmp/no_such_file # readlink -f /tmp/some_symlink /tmp/no_such_file Created attachment 6141 [details]
Fix dropbear when readling is busybox
CAre to test the attached patch and report back, please?
Yes, this patch worked for me. Tested-by: Jason Tang <tang@jtang.org> |