Directory structure as seen from Telnet?

Black Hole

Black Hole

May contain traces of nut
I'm having a bit of a problem understanding what I am seeing via Telnet. I want to copy some files from the external Ext3 drive to the external NTFS drive, and although the SUI lets me press the copy button nothing actually happens when I do.

So I thought I would set the Humax into non-auto-powerdown mode and do the copy via cp command in Telnet. The trouble is I have explored "ls -l" and "ls -l mnt", "ls -l mnt/hd1(2,3,4)" but can't see anything I recognise as being the external drives.

Perhaps somebody can explain what's in the directory structure we see with "ls -l /"?
 
What you see when you type "ls -l /" is the root file system (i.e. the flash memory). However, you can mount other drives anywhere in that filesystem. To get a list of these "mount points", just type mount, you we see something like this:

Code: 
 mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /tmp type tmpfs (rw)
tmpfs on /media type tmpfs (rw)
/dev/mtdblock1 on /var/lib/humaxtv type jffs2 (rw)
/dev/mtdblock2 on /var/lib/humaxtv_backup type jffs2 (rw)
/dev/sda1 on /mnt/hd1 type ext3 (rw,data=ordered)
/dev/sda2 on /mnt/hd2 type ext3 (rw,data=ordered)
/dev/sda3 on /mnt/hd3 type ext3 (rw,data=ordered)
/dev/sda2 on /media/virtual type ext3 (rw,data=ordered)
/dev/sdb1 on /media/usb-drive1 type fuseblk (rw,user_id=0,group_id=0,allow_other)
The three hard disk partitions are /dev/sda1, /dev/sda2 & /dev/sda3 and you can access them form /mnt/hd1 to /mnt/hd3. The Humax GUI normally looks for things under the directory /media. This is a temporary directory (it uses the tmpfs - see above) and is recreated on boot. Within that directory are symbolic links to point My Video etc to their actual locations (see 'ls -l /media').

The ntfs-3g filesystem uses a user-space driver which is type fuseblk in the mount listing above.

Hard disks are usually labelled as /dev/sda, /dev/sdb etc. Partiitions on those drives are /dev/sda1, /dev/sda2 etc.

To copy a file from one drive to anther you just need to copy it from/to the appropriate directories under /media.
 
Ah! So I should have been looking in /dev. I think I should have known that, but I read it as "development" not "device"!

:oops:
 
Black Hole said:
Ah! So I should have been looking in /dev. I think I should have known that, but I read it as "development" not "device"!

:oops:
Click to expand...
The devices in the /dev directory are the raw devices - they do not have a file system associated with them. You should access the files using the mount point (usually in /media or /mnt).
 
Yep, doing that now. I have a big copy in progress (85GB) - I'll let you know how long it takes!
 
Aarrrgghh!

I've just discovered that when I put my PC to sleep the Telnet sessions dropped the line and the copy operation terminated (I had the copy running in one session and I was monitoring progress in another).

Is there some magic incantation I can use to "cp *" without repeating the files that have already been copied? Is there a way to keep the copy process active without having to keep the Telnet session open??
 
rsync is your best bet as it brings the two trees into sync. Something like the following, with paths suitable adjusted and make sure the rsync package is installed.

Code: 
humax# rsync -avr /media/drive1/ /media/usb_drive1/

Don't forget the trailing / characters on each directory and the arguments are in the order of source and then destination.
 
Oh dear. This is what I got when I tried to install rsync:

Runtime Error: /mod/var/mongoose/lib/pkg.class:56: Collected errors: * opkg_conf_load: Could not lock /tmp/opkg.lock: Resource temporarily unavailable. in procedure 'pkg' called at file "pkg.jim", line 60 at file "/mod/var/mongoose/lib/pkg.class", line 56
Click to expand...

Once I get past that, I presume rsync will also require the Telnet session to stay open?

Update: Well, what do you know? I just listed the packages again and rsync is in the installed list!
 
You can run the command (rsync, cp or whatever) in background by adding ampersand '&' to the end of the line. It will continue to run when the telnet session is closed.
 
<sigh>

I thought the cp operation had bombed out, but looking at the timestamps I can now see that it had not and it has been working away in the background ever since.

So now I've started up "rsync ... &", I don't know what's happening. However, I do notice cp gave the copied files new timestamps whereas rsync preserves the timestamps.
 
Type 'ps' to see which processes are running on the system and 'kill PID' where PID is the process ID from the ps listing to stop any of the processes.
 
Thanks for that, I just killed my rsync process (which was three processes in the table), and the cp is still running (and the drives are flashing).
 
Something's gone seriously wrong. A .ts file which should be 4.4GB is now up to 18GB on the copy.

Update: I stopped the process, then tried it again and similar happened. A clue is that the copy which normally was taking 20 minutes for a 4GB file was suddenly clocking up at the destination at 2GB/min. I tried it with one .ts and another .*, the non-ts files were not a problem but the second .ts didn't terminate (the same as the first). I don't think the sources were broken. I'm going to try rebooting and have another go.

Bugger, can't reboot because it's recording something.
 
You must log in or register to reply here.
Back
Top