The problem that I encountered today (on an embedded device with Linux) is that some files (specifically, the Valgrind /usr/lib files) are behaving very strange and they are not copy-able with scp (error is: not a regular file).


$ ls -al /usr/lib/*valgrind*
drwxr-xr-x    2 root     root          4096 Sep 30 00:01 .
drwxr-xr-x   24 root     root         12288 Sep 30 00:00 ..
-rwxr-xr-x    1 root     root       1816444 Jun  6  2014 cachegrind-x86-linux
-rwxr-xr-x    1 root     root       1910732 Jun  6  2014 callgrind-x86-linux
-rw-r--r--    1 root     root         28429 Jun  6  2014 default.supp
-rwxr-xr-x    1 root     root       1884080 Jun  6  2014 drd-x86-linux
-rwxr-xr-x    1 root     root       1770688 Jun  6  2014 exp-bbv-x86-linux
-rwxr-xr-x    1 root     root       1852668 Jun  6  2014 exp-ptrcheck-x86-linux
-rwxr-xr-x    1 root     root       1910200 Jun  6  2014 helgrind-x86-linux
-rwxr-xr-x    1 root     root       1778880 Jun  6  2014 lackey-x86-linux
-rwxr-xr-x    1 root     root       1792524 Jun  6  2014 massif-x86-linux
-rwxr-xr-x    1 root     root       1942904 Jun  6  2014 memcheck-x86-linux
-rwxr-xr-x    1 root     root       1766560 Jun  6  2014 none-x86-linux
-rwxr-xr-x    1 root     root          2620 Jun  6  2014 vgpreload_core-x86-linux.so
-rwxr-xr-x    1 root     root         65296 Jun  6  2014 vgpreload_drd-x86-linux.so
-rwxr-xr-x    1 root     root         17904 Jun  6  2014 vgpreload_exp-ptrcheck-x86-linux.so
-rwxr-xr-x    1 root     root         37908 Jun  6  2014 vgpreload_helgrind-x86-linux.so
-rwxr-xr-x    1 root     root         15128 Jun  6  2014 vgpreload_massif-x86-linux.so
-rwxr-xr-x    1 root     root         26652 Jun  6  2014 vgpreload_memcheck-x86-linux.so

First of all, notice that they do not have "valgrind" string in their names.

Then, they are shown as regular files (not pipes, not devices). But, very strangely, they are not found by simple ls:

$ ls -al /usr/lib/memcheck-x86-linux
ls: /usr/lib/memcheck-x86-linux: No such file or directory

They don't even show in the regular listing:

$ ls -al /usr/bin

What on Linux could cause that behaviour?

More, there is no utility like "file" on the device, but I doubt that would help me much.

Output of df:

$ df
Filesystem           1024-blocks    Used Available Use% Mounted on
/dev/root               980308    175548    754964  19% /
tmpfs                    10240       112     10128   1% /dev
tmpfs                   246728         0    246728   0% /tmp
tmpfs                     2048        12      2036   1% /var/log
tmpfs                   246728       128    246600   0% /dev/shm
tmpfs                   246728         0    246728   0% /run
tmpfs                   246728        20    246708   0% /var/run

So, / is a device.


$ whoami

So, I am root.

Just to complete the puzzle:

$ ls -al /dev/root
ls: /dev/root: No such file or directory

So the device that is mapped does not really exist.


This output:

$ ls -al /usr/lib/*valgrind*
drwxr-xr-x    2 root     root          4096 Sep 30 00:01 .
drwxr-xr-x   24 root     root         12288 Sep 30 00:00 ..
-rwxr-xr-x    1 root     root       1816444 Jun  6  2014 cachegrind-x86-linux

indicates that there is a directory named /usr/lib/*valgrind* (most likely just /usr/lib/valgrind) which you're listing. The biggest clue is that you're seeing directory entries for . and ...

That explains why ls -al /usr/lib/memcheck-x86-linux says the file doesn't exist - it's because the file is called /usr/lib/valgrind/memcheck-x86-linux.

If you don't want to list directories and show them as one entry instead, add the -d flag to ls:

$ ls -ald /usr/lib/*valgrind*
drwxr-xr-x    2 root     root          4096 Sep 30 00:01 /usr/lib/valgrind

As for why scp is saying "not a regular file", since you didn't provide the scp command line or output I have to guess, but my guess is that that is the output your scp produces for an argument that isn't any kind of file at all, because it doesn't exist.

  • OMG. I'd wish to never ask that question! I feel so dumb! Thanks a lot! I was looking for too complicated answers! – user1284631 Jul 25 '14 at 8:48
  • Good power of deduction! – chaos Jul 25 '14 at 8:57

While Michael Homer already wrote what happened, here's why it happened (given your comment on his answer I think you already know, but others coming across this question might not).

The command you issued was

ls -al /usr/lib/*valgrind*

The stars are interpreted by the shell even before ls is executed, by replacing it with a list of filenames matching the pattern. Now if there's only one matching name (say, /usr/lib/valgrind), then of course the list will contain just that one name. So the command which actually gets executed is

ls -al /usr/lib/valgrind

Now ls will see that it is given a single argument, and checking that single argument reveals that it is a directory. Since you didn't give the -d option, for directory names it will list not the entry of the directory, but the contents of the directory. And since it was given only a single directory name, it also will not print the directory name first (since if you give a single directory name as argument, there's no question to which directory the listed files belong; remember that ls has no idea that the directory name came from a file name expansion).

If you want to know the actual name of the directory (remember, the literal /usr/lib/valgrind was a guess (although a very likely one); it might as well be /usr/lib/valgrind-3.7), you can use

ls -ald /usr/lib/*valgrind*

Also note that if there happens to be an additional hidden directory .valgrind or a hidden file like .valgrind-foo in /usr/lib, it will not be shown by your ls command, despite the -a option, because the shell expansion doesn't care about the options you gave to ls, and ls will then have no idea that you want to see those files as well, since they are not included in your file list. So if you want to male sure that dot files are listed as well, you'll have to use:

ls -ld /usr/lib/*valgrind* /usr/lib/.*valgrind*

Note that -a is not needed here, since dot files given as arguments are unconditionally listed by ls. Of course if you want to list the contents of any directory having valgrind in its name, including the dot files, you will need -a, since those dot files don't appear on the command line after expansion. That is, in that case you'd use

ls -la /usr/lib/*valgrind* /usr/lib/.*valgrind*

On the other hand, if you are interested in the content of directories matching .*valgrind*, but not in the dot files contained therein, you'd not use -a.

If you are using bash (and possibly also for other shells, but there I'm not sure), you can simplify the previous two commands to

ls -ld /usr/lib/{,.}*valgrind*


ls -la /usr/lib/{,.}*valgrind*
  • true and thanks. upvoted. of course, once it have been stated, it became so obvious to me. I know all the commands, but thanks again. I think I was disturbed by so many, many files inside the /usr/lib folder, that I did not see the ./valgrind folder therein and then started imaging strange things. still surprised to receive upvotes on such dumb (a posteriori) question... – user1284631 Jul 25 '14 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.