Pádraig Brady wrote: > Jim Meyering wrote: >> Pádraig Brady wrote: >>> Jim Meyering wrote: >>>> Thanks for the review. >>>> BTW, here's the merged version: >>> And attached one handles the `ls -Ls` case, >>> which I'll push soon. >>> >>> cheers, >>> Pádraig. >>> >From 3edaa2363db0367e8fa472c4dc5c5696537cde61 Mon Sep 17 00:00:00 2001 >>> From: =?utf-8?q?P=C3=A1draig=20Brady?= <[email protected]> >>> Date: Tue, 29 Sep 2009 15:43:01 +0100 >>> Subject: [PATCH] ls: always print "?" for allocated size of a dereferenced >>> dangling symlink >>> >>> Previously for `ls -Ls` (but not `ls -Lsl`), we referenced >>> the st_blocks returned from the previous failed stat() call. >>> This undefined value was seen to be 0 for danglink symlinks at least. >>> * src/ls.c (print_file_name_and_frills, length_of_file_name_and_frills): >>> Don't use st_blocks if the previous stat() failed >>> * tests/ls/dangle: Add a test case >>> * NEWS: Mention the bug fix >> >> Good catch. Thanks! > > The NEWS is getting a bit verbose on this minor issue. > Unless there are objections I'll roll up the NEWS from: > > ls -Li is now consistent with ls -Lil in printing "?", not "0" as the > inode of a dangling symlink. > > ls -Li no longer relies on unspecified behavior of stat/lstat. > Before this change, "ls -Li dangling-symlink" would mistakenly > print the inode number of the symlink under some conditions. > > ls -Ls is now consistent with ls -Lsl in printing "?", not "0" as the > allocated size of a dangling symlink. > > to: > > ls -is is now consistent with ls -lis in ignoring values returned > from a failed stat/lstat. For example ls -Lis now prints "?", not "0", > for the inode number and allocated size of a dereferenced dangling symlink.
Agreed. Thanks.
