bugfindutils - Bugs: bug #45780, inode column is badly aligned when...

 
 

bug #45780: inode column is badly aligned when running 'find <dir> -ls'

Submitter:  Hans Deragon <deragon>
Submitted:  Mon 17 Aug 2015 04:56:48 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  jay
Originator Name:  Open/Closed:  Closed
Release:  4.4.2 Fixed Release:  4.5.15
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 31 Oct 2015 11:40:09 PM UTC, comment #8: 
James Youngman <jay>
Group administrator
Sat 31 Oct 2015 03:10:49 PM UTC, comment #7: 

Special-casing the first 1024 entries doesn't really work well in the current design of find.   So instead, I'm going to borrow an idea from the ls in GNU findutils (though, unlike ls, find does not process a whole directory at one time, so the technique will be less powerful here).   I will commit a patch shortly.

James Youngman <jay>
Group administrator
Wed 28 Oct 2015 01:40:39 PM UTC, comment #6: 

What if you put some intelligence into find?  Fetch the first 1024 entries and figure out the biggest inode number.  Then use that value as the size of the inode.  Probably most of the time, it will be ok for the rest of the output.

This would mean to cache the first 1024 entries if find is called interactively.  However, if piped, then current behavior prevails.  An option should be provided to force the 1024 entries behavior even when piped in case someone wants to save the output for a report and wants proper alignment.

There could also be an option to cache all entries and properly align the output.  Another one would allow to change the default 1024 value.  There could be an option to force the size of the column, no question asked.

There are a lot of options.  It is up to you to decide what is best, and what you can actually do with the time you have.

Hans Deragon <deragon>
Mon 26 Oct 2015 07:10:55 PM UTC, comment #5: 

I just made an implementation of my suggestion in #3 and I'm not sure I like it because the resulting field is very wide and mostly blank.   On my development system this results in a 20-character field for the inode number (since, I assume, ino_t is a 64-bit type).  

I agree though that a filesystem which supports only a million files would be small by today's standards.

It's tempting to use statfs to examine the filesystem and use statfs.f_files but this only tells us the maximum number of files - the inodes may not be allocated in any particular way (e.g. not contiguously).

James Youngman <jay>
Group administrator
Wed 02 Sep 2015 06:33:03 PM UTC, comment #4: 

find version under Ubuntu 14.04 LTS Trusty Thar:

$ find --version
find (GNU findutils) 4.4.2
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Built using GNU gnulib version e5573b1bad88bfabcda181b9e0125fb0c52b7d3b
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=0)

Hans Deragon <deragon>
Thu 20 Aug 2015 10:26:26 PM UTC, comment #3: 

Well, find could determine the maximum field length by doing something like printing ((ino_t)~0).

To discover which version of find you are using, use "find --version".  If it doesn't print the version information, it is not GNU find.

For what it's worth, trying this on my machine here turns up some 10-digit inode numbers, so those would certainly be misaligned.

James Youngman <jay>
Group administrator
Thu 20 Aug 2015 08:32:04 PM UTC, comment #2: 

I tested it under Ubuntu 14.04 LTS.  I have no clue if it is pure GNU find or not.  However, you are right about the mangled output of my example.  Still, 6 characters is not enough; it should be increased.  In /var, I have a lot of inodes using 7 characters (at least half).  In another of my filesystems, they are all 7 characters long.  What about you?  Does it often goes over 6 characters?  Maybe its time to increase the default from 6 to 8?

And under Cygwin (Windows), it is worse.  16 characters are needed minimum.  So if there is a conditional compilation flag and cygwin is detected, I would increase it to 16 characters.

$ find --version
find (GNU findutils) 4.4.2
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Built using GNU gnulib version e5573b1bad88bfabcda181b9e0125fb0c52b7d3b
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=0)

Hans Deragon <deragon>
Mon 17 Aug 2015 09:54:58 PM UTC, comment #1: 

Thanks for the report.
However, your example output seems to be mangled: as find(1) is
using "%6s " for the inode numbers, you cannot get a smaller
inode "column" than 6 characters.


$ find/find /home /var /dev /media -maxdepth 0 -ls
     2    4 drwxr-xr-x   9 root     root         4096 Nov  9  2014 /home
262146    4 drwxr-xr-x  12 root     root         4096 Nov  9  2014 /var
  1025    0 drwxr-xr-x  18 root     root         4580 Aug 16 22:27 /dev
1048577    4 drwxr-xr-x   6 root     root         4096 Nov  9  2014 /media

Are you sure you are using the original GNU find? (Downstream
distributions may have added patches to modify this behaviour btw.).

Anyway, the basic observation is correct: the alignment may vary
among the output lines.

The reason is that find(1) outputs the -ls line per entry immediately,
while "ls -dils" internally calculates the biggest inode number width
of all arguments prior to actually outputting the entries.

The point is that find(1) is made for an unlimited number of entries
to find, thus making it impossible to internally calculate and store
all entries like ls(1) does.

BTW: ls(1) does the same pre-calculation on a per-directory
basis when running recursively, i.e., you may get different
alignment due to the inode numbers at least for each
(sub-)directory.

Bernhard Voelker <berny>
Group administrator
Mon 17 Aug 2015 04:56:48 PM UTC, original submission:  

Running 'find <dir> -ls' prints out the inode column without any alignment.  Oddly, running 'ls -dils' on the same directory shows proper column alignment.

$ find /var -ls
778    4 drwxr-xr-x   2 someuser     someuser         4096 Jul 25 10:10 /var/<somefile>
1581140    4 drwxr-xr-x   2 someuser     someuser         4096 Jul 25 10:09 /var/<somefile>
1592791    4 drwxr-xr-x   2 someuser     someuser         4096 Jul 25 10:10 /var/<somefile>
270190    4 drwxr-xr-x   2 someuser     someuser         4096 Jun  7 18:53 /var/<somefile>
265565    4 drwxr-xr-x   2 someuser     someuser         4096 Jun  6 07:07 /var/<somefile>
  9796    4 drwxr-xr-x   2 someuser     someuser         4096 Jun  7 18:53 /var/<somefile>
  9798    4 drwxr-xr-x   2 someuser     someuser         4096 Jun  7 18:53 /var/<somefile>

Hans Deragon <deragon>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by deragon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-12-18 jay Open/ClosedOpen Closed
        Fixed ReleaseNone 4.5.15
    2015-10-31 jay StatusNone Fixed
    2015-10-26 jay Assigned toNone jay

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code