I have inadvertently deleted several files from my external usb ntfs drive and would like to try to recover them using ntfsundelete.

The files are likely intact, since I don't write to the drive often.

I have found the program ntfsundelete, but it expects you to give it a "device" specification for the target drive. I have a "mountpoint" '/media/MyBook', but I don't know how to determine the corresponding device to use with ntfsundelete.

How do I determine the "device" specification for a "mountpoint" for a usb external drive?

Thanks in advance for your help.

To see all the block devices and shares currently mounted on your system, type the "mount" command without any arguments. It will show you the contents of /etc/mtab.

You can also run "fdisk -l" to see all the block devices available to your system, mounted or not.

I have often wondered this question myself - how do I get the device which is mounted under a particular directory, giving it JUST the directory? Is there a command for this? Does the Linux kernel allow for it?

I'm not aware of such a command, but you can use one of the methods suggested by David the H. above, or simply the df command:
a simple parsing using awk can extract just the information you need:
Moreover you can "create" your own custom command using a shell function, e.g.
Then just run:
in case the mount point does not exist, you will get nothing since the redirection of standard error from df to /dev/null.

Well that's the easy solution (mount | grep directory) , but what I really wanted to know is - is there a way to query the Linux kernel itself as to which device lies under a particular directory? I think this is one of the mistakes Linux made by making everything a file, that is, when you mount, you give it the name of a device which is a file ("/dev/sda"), and then a directory, which is also a file, that is - you're mounting a file under a file!!!!, which doesn't make sense.....

These days this is usually handled by udev (if I correctly understand what you are asking).

Joke, right?

Evo2.

when you plug your usb device into your computer and do a mount or df command, what did you see ? normally, something like /dev/xxxx where xxx is anything. that's your [device] to pass to ntfsundelete. On my system, its /dev/sdb1, so the command is
make sure you unmount /dev/sdb1 before using.

What you think of as a file is really just a name. It's a string in a directory that references an inode. Inodes can be regular files or any of several other things like directories (such as where the name to inode reference itself is stored), or devices.

This simplifies programming because you can open things other than regular files using just the same mechanism (API) as for regular files. So once you know the name of the device and have it in a string, you can open the device.

I can, for example, copy one whole hard drive to another like this:

cat < /dev/sdd > /dev/sde

If they are exactly the same size, the whole drive will be copied. In this case the shell will open each drive and pass the descriptors to the "cat" program it runs. Opening devices will usually require elevated permissions (because doing so could reveal info not intended for all users, or allow a user to disrupt and destroy the system).

There is then an ioctl() syscall to get meta information about the opened object that is very specific to what is opened. For block devices, a particular ioctl() call can store a number indicating the size of the device if the kernel knows it.

You can get the names of the mounted devices through a special file called "/proc/mounts". This is the name as it was known when the device was mounted, or the kernel's best determination of the name. Only in extreme instances (like someone deleting a link name in the "/dev" directory) will the information be unusable.

"/proc/mounts" will be more reliable than the "df" command or reading "/etc/mtab" in most cases ... as long as the special "proc" filesystem is mounted at "/proc" (it usually is).

That said ... if you are going to run a program to diagnose and repair a filesystem via its device (that's usually how it is done), then the file system in question should NOT be mounted. If it is mounted, you can note what the device name is, unmount the filesystem, and run the utility giving in that device name. In the case of plugging in a new device, it will typically be automounted. But if not, you can run the "dmesg" command to example what recent messages say about a device being probed. Or you can output the contents of the special file "/proc/partitions" to see what mountable block devices (and their sizes) the kernel believes it has available.