Project

General

Profile

Actions

Bug #48912

closed

ls -l in cephfs-shell tries to chase symlinks when stat'ing and errors out inappropriately when stat fails

Added by Jeff Layton over 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
% Done:

0%

Source:
Development
Tags:
Backport:
pacific
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
cephfs-shell
Labels (FS):
task(easy)
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

ls -l in cephfs-shell tries to chase symlink targets when stat'ing. For example, from the kclient:

$ ls -l
total 1
drwx------. 3 jlayton jlayton 6 Jan 18 08:29 crypt
lrwxrwxrwx. 1 jlayton jlayton 5 Jan 18 08:36 testlnk -> crypt

...but if I do the same in cephfs-shell:

CephFS:~/>>> ls -l
drwx------          141 4447 4447 2021-01-18 13:29:38 crypt/
drwx------          141 4447 4447 2021-01-18 13:29:38 testlnk

...the symlink shows up as a directory instead. The stat needs to use AT_NOFOLLOW_SYMLINKS, or lstat().

On a related note, ls -l also aborts if a stat comes back with an error. It should instead do what "real" ls does and display '?' characters in the relevant fields, and continue on. For example, from kclient:

[jlayton@client1 vstart]$ ls -l testlnk
lrwxrwxrwx. 1 jlayton jlayton 3 Jan 18 08:40 testlnk -> foo

...but from cephfs-shell:

CephFS:~/>>> ls -l testlnk
opendir failed: No such file or directory [Errno 2]

Related issues 1 (0 open1 closed)

Copied to CephFS - Backport #49685: pacific: ls -l in cephfs-shell tries to chase symlinks when stat'ing and errors out inappropriately when stat failsResolvedVarsha RaoActions
Actions

Also available in: Atom PDF