I was browsing through my system looking for patterns and testing some scripts when I happened on /usr/bin and did "ls -l /usr/bin/git*" and got 147 files and most of them are exactly 781368 in length. WTF. I am not sure why it was done this way and there is git-rm and many more that seem to be poorly designed knockoffs of each other. I don't usually use git, but I am going to investigate further to see what the hell this is doing that it needs 100 megs to implement version control.
Update after doing "ls -laisS /usr/bin/git*" I realized that they are just soft hard links that reference the same inode. It was an interesting tour and I always like to learn new things. I still do not understand how to display them as being simple aliases and so I will study the man for ls some more and do a little research.
More: I should have known since the fourth column had 83 in it to indicate 83 hard links to the same inode. I guess that I thought that ls -la would distinguish that fact by color, but WTH (What the hey) the information is there. I did "find -L /usr/bin/ -inum 614529 -ls | wc" and it showed 83 items that connected to that inode. BTW the order of options in find is important as the "-ls" is a command to be executed after the tests and not before.
The principle is that when the inode count is 0 then the "real" data is erased from my understanding and so I was simply confused by my own intelligence DOH! I have studied the structure of the file systems and know NTFS and all the DOS types and FAT16 and FAT32 and MBRs and also the EXT. I just get confused sometimes by the context I guess. (Making excuses for my failures is one of my greatest assets) I could be more informed about the UNIX file systems, but that will wait until I have a hard disk crash and then I will embark on a "crash" course. It is not always useful to understand things in that detail if you have a friend that knows the journaling file system.
0 comments:
Post a Comment