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. cheers, Pádraig.
