Some files don't copy -- some do -- and there's never a message.

[AtlantaBob]

Well, the forums have certainly changed....

I'm running Red Hat Enterprise Linux Desktop edition 4 on a Dell SC420.

On a couple of occasions now, I've tried to copy a directory over to a usb flash drive (actally, a few flash drives), and in many cases -- not all -- subdirectories or files in the original directory are not fully copied. For instance, I'm copying ~/thesis, and subdirectories /chapter2 and /chapter3 will copy, subdirectories /chapter4 and /chapter5 won't, and the file /chapter2/othernotes.tex will be missing, even though the rest of the /chapter2 is there....

In some cases, the copy proceedes very fast--as in a copy status bar never appears. This is significantly faster than a similar copy operation in windows (taking 3-5 seconds).

So... um, help?

Thank you!

 

[child of wonder]

Run "sync" after you do the copy.

 

[AtlantaBob]

Many thanks! I guess that (in this version at least) gnome doesn't automatically run sync when the user unmounts the drive?

 

[child of wonder]

Normally Linux mounts with the sync option enabled by default but not with FAT.

From "man mount"--

The following options apply to any file system that is being mounted (but not every file system actually honors them - e.g., the sync option today has effect only for ext2, ext3 and ufs).

 

[AtlantaBob]

Hm. I did that, however, again, only a few of the files copied over. Sync ran, no problem. Could it be something else?

 

[AtlantaBob]

That being said, cp -r ~/thesis /media/CORSAIR seems to work just fine. Could it be an issue with gnome?

 

[child of wonder]

Permissions problem?

 

[Nothinman]

If you actually unmounted the drive before pulling it out it should have done the equivalent of sync, did you do that?

Also check out ~/.xsession-errors, if any part of Gnome printed warnings/errors to stdout they should be captured there.

 

[AtlantaBob]

Hi guys. Thanks for looking at this. I've checked the permissions on a few of the files/directories that didn't copy -- I'm the owner of all of them, and I have read/write access to all of it. Even if I wasn't the owner, others still have read/execute privlides, which means they should be allowed to copy, right? (Also, I was using the cp -r... command within Gnome, so I'm still the same user there).

I did inded unmout the drive before pulling it out.

Also, I checked .xesssion-errors -- the file doesn't exist in my home directory -- I know it's hidden -- I used tail .xsession-erors and it told me it didn't exist. Only auto-complete entry for it was .xscreensaver

Any other ideas? Thanks!

 

[Nothinman]

Also, I checked .xesssion-errors -- the file doesn't exist in my home directory -- I know it's hidden -- I used tail .xsession-erors and it told me it didn't exist. Only auto-complete entry for it was .xscreensaver

How are you getting into X then? You're not logging in on the console and running 'startx' are you?

 

[AtlantaBob]

no, I'm not. It boots into X/gnome automatically at startup.

I just ran "find -name .x* from the root directory and it only came back with the .xscreensaver file (and a few directories that I couldn't access)
To be sure I wasn't missing anything, I just ran the same command as root -- no results, other than the .xscreensaver.

?

 

[Nothinman]

Odd, I've never used RHEL for a desktop but I would have assumed that they use GDM which should write ~/.xsession-errors for you.

 

[AtlantaBob]

This may be a good incentive for me to move to Ubuntu when the project that I'm using this for is over. At the moment, I suppose I'll just copy to the command line. Thanks again for your help!

 

[uOpt]

Check /var/log/message or /var/log/syslog depending on distribution.

 

[drag]

Don't be offended, but it sounds like you may be pulling the drive to soon.

If you go and umount through the GUI it probably isn't going to give you proper feedback on how long it is taking to actually umount the thing. Redhat 4 is going to use a rather old version of Gnome.. although I don't know if it's gotten that much better lately.

I know with flash based devices it can take a very long time. Maybe upwards to 5-10 minutes for it to finish writing out large files.

Generally you can expect a flash device to write out maybe 8-15KB/s. Newer ones can be faster... much much faster... but I assume this is just one of those generic things.

And then when you have bunches of small files (which seems to be what is going on) then it can get _VERY_ slow on some drives. Your looking at 0.5 KB/s and even slower.

Now this is on Windows, and I expect Linux to be a bit faster, but I am just going off of published benchmarks like: http://www.anandtech.com/memor...owdoc.aspx?i=2549&p=26

If your not working directly from flash you may want to disable the gnome automount stuff and set it up to mount with 'sync' option through fstab. This way it will flush the buffers continuously and write things to the drive immediately. This will cut down on chances of things going wrong by quite a bit.

This is what it sounds like to me. Pulling the drive too soon would definately cause missing files and such things. It's a very easy mistake to make. It could be lots of other things wrong, but I just wanted to throw this out there.


Of course another distinct possibility is just that the USB stuff from Redhat's kernel is buggy. 2.6 kernels had some rocky times with USB support and RH 4 is running a rather old system.

 

[AtlantaBob]

drag,

No, I'm not offended. I just am not sure that that is what's happening.... I'm only copying a little more than 1 MB of files over to the drive at a time (thank goodness for the text format!) Also, the drive is a fairly fast, recent (1GB) Corsair flashdrive. I'm definitely with you on the time that it takes to copy lots of small files, but here, there aren't more than 35, tops.

When I copy via the command line and then check to see that the files are there in the GUI (including opening them to see if the're really copied), they're there after 5 seconds or so. Just to be safe, sometimes I've left the drive in for 2 minutes or more... and I still get the same issue. I tend to think that it may be a bug in the software... newer versions of ubuntu (on another computer, but same flash drive) don't seem to have the issue at all.

uOpt -- I've checked /var/log/messages, what I see doesn't seem to have anything to do with the flash drive, but has a number of messages saying localhost dbus: Can't Sent to audit system: USER_AVC pid=3657 [more options, etc.]. then about every minute, after that sayng localhost last message repeated 13 times. I'm not sure what's going on there, but it doesn't sound like a flash drive thing.

Anyway, it does seem like a good reason to upgrade soon, huh? Thanks again for all of the help, guys!

 

[Fallen Kell]

Change the way you are doing the copy. The best way to copy any amount of files is actually to use a tar command because it both verifies that a complete, uncorrupted copy is made as well as keeping original file permissions, and not only that, it will give you feedback as to where it is in the copy... The secret command is as follows:

cd <to the directory that you want to copy>
tar cf - . | (cd <destination dir>; tar xvf -)

You can even do this to a second system if you have trust setup (you can use rsh as well instead of ssh):
tar cf - . | ssh <destination host> '(cd <destination dir>; tar xvf -)'


Again, benefits are that files are checked upon copy, permissions are kept, and you will see each file named as it is extracted into the destination folder.

edit: explaination of how command works:
"tar cf": create a new tar
"-": a dash for the output file name means use the standard out which will simply output to the screen or terminal window
".": means use the current directory for the input
"|": means pipe all standard output to the following command as "standard input"
"( )": arround any set of commands means invoke in a new subshell
"cd <destination dir>;" means exactly what you think, the ";" tells the subshell that it is the end of the first command a simple way so that you can write multiple commands in a single line instead of having to hit the return key
"tar xvf -": means extract the tar archive which is located at "standard input". The "-" is used to denote both standard input and standard output under unix shells depending on if you use it in place of an input file or output file handler.

As I said, you can wrap other commands into this as well if you want...