Copying from HDD to USB flash drive

[Grey]

People, how does the process of copying from a hard disk to a USB flash drive go for different users?

Fossapup. I drag the file from the first window to the second. A window appears with a message about copying, but it quickly goes away. But copying continues for a long time, because the indicator on the flash drive is blinking.

That's why all my flash drives have an LED. And how is this process going with you?

[JASpup]

I noticed recently in my simplified menus project that there are a lot of Puppy utilities for data manipulation that I never looked at before. I bet some of them work. If an app has a technical label I won't find it unless I am looking for it.

I rely on copying the same way I backup:

a) dd command by partition (not the whole drive)
b) AOMEI Backupper in Wintopia

So essentially full drives are copied by restoration.

If you are copying with Roxfiler, usually the copy window stays open for the full copy, but I can imagine your results even though they sound a bit glitchy.

[Grey]

The conditions are of course standard. Rox, and the file size is gigabyte or more.

[bigpup]

I assume you are doing this in a specific file manager.

To give you specific info.

What file manager?

Most file managers have some preference settings that could affect this.
So need to look at them.

[MochiMoppel]

A window appears with a message about copying, but it quickly goes away. But copying continues for a long time, because the indicator on the flash drive is blinking.

More or less what you should expect.

And how is this process going with you?

Different.
The message stays for a long time and the indicator keeps blinking for a short time. BTW: also reading takes a long time. The HD indicator blinks almost as long as the USB indicator

I assume that the difference is your RAM: If you have 64GB (already more than my largest USB stick ) then you also have a big OS I/O cache. From ROX-Filer perspective copying is done as soon as the cp command, which is what ROX-Filer uses for copying, exited without errors. Time for ROX-Filer to close the message. The actual I/O work continues and your LED keeps blinking.

It is possible to keep the ROX-Filer message open until all data are actually copied, but that wasn't your question, was it?

[Grey]

It is possible to keep the ROX-Filer message open until all data are actually copied, but that wasn't your question, was it?

Hello. I can flexibly adjust to the situation and change the question If the window about copying is open, then I will be able to use a USB flash drive without an indicator and understand the process from this window.

What method do you suggest? Something with the /root/.config/rox.sourceforge.net/ROX-Filer/Options file or something more tricky?

[JASpup]

Thunar shows a progress display I have noticed recently. Win 10 has one a bit more advanced, highlighting the variable data transfer rate. I might call at least the Thunar progress a 'must' for large data copies. Alas, I only use Thunar in XFCE or Tahr for partition mounting.

XFE also has a very basic % copy progress display. I just copied 62M in tmpfs that fast but enough data to see the display go 0-100%.

I like Roxfiler's running file list and red error reporting, but you are not going to see those if your copy dialog is closing abruptly. Of course we can also get copy progress by filename cli with the -v switch.

[MochiMoppel]

What method do you suggest? Something with the /root/.config/rox.sourceforge.net/ROX-Filer/Options file or something more tricky?

Nothing tricky, nothing sinister

I suggest that you try to

1) Rename your original cp binary /bin/cp to something like /bin/cp_org
2) Create a script /bin/cp with contents
#!/bin/sh
cp_org "$@" && sync

After making the script executable it will act as a wrapper for the original cp binary. All calls made to cp will now be passed to /bin/cp_org. The additional sync command will write the cache to the target disk. The "trick", if you will, is the exploitation of ROX-Filer's strange reliance on the cp command. ROX-Filer will close its message when the cp application finishes, but with cp now being a script it has to wait until the trailing sync command finishes too. In other word: The message will disappear when all data are copied.

[MochiMoppel]

@Grey Solved?
Your problem - if there still is one - affects not only "copying from HDD to USB flash drive" but moving files as well, between any device. e.g. USB to USB.

@JASpup As long as it remains unclear what progress is monitored a progress bar or display can be very misleading. I doubt that all the other file managers you mentioned are much better in this respect than ROX-Filer.

[JASpup]

@JASpup As long as it remains unclear what progress is monitored a progress bar or display can be very misleading. I doubt that all the other file managers you mentioned are much better in this respect than ROX-Filer.

The progress is the aggregate data being transferred, and seeing a percentage over a running list of files helps.

Other users have aesthetic/ergonomic comfort issues.

I feel less mislead rather stymied by default functioning.

Using four file managers isn't high on my list of problems, but it does seem excessive.

This is no request but I would make XFE builtin in JWM pups and see what happens.

[Flash]

The way I tell when the actual copying is done is, after the copy process is started and everything seems to be proceeding as desired, I click on the little x on the drive symbol that indicates the drive is mounted. The x won't go away, indicating the drive is actually unmounted, until the OS is done with copying and all the housekeeping associated with it,

[Grey]

Solved?

We should start with the fact that the method for some will still be "trick" Because after renaming at the first step, it will be problematic to create a script or copy it from another folder. Alternative managers help with this, I used Double Commander.

Now the method itself. It works. Only for Rox. Does not affect Double and Xfe in any way (and they also have problems, there is even a Copy Pause in DC that you do not have time to press). But this is expected.

Rox filer now behaves "decently". The "copy" window disappears simultaneously with the moment when the flash drive indicator stops blinking.

Is it worth implementing this as a fix for common Puppy distros? Or is everything fine in other variants?

I checked on two flash drives. Kingston 8GB (2.0) and Silicon Power 64GB (3.1). I use them at the moment in order to carry 10-20 episodes of a TV series to the kitchen and watch there.

[MochiMoppel]

after renaming at the first step, it will be problematic to create a script or copy it from another folder..

I tried to keep the description short. Though you can always use the renamed command (cp_org) or busybox cp from a command line, the safest way is to create the script first with a different name (e.g. cp.sh) , rename the original and lastly rename cp.sh to cp

Rox filer now behaves "decently". The "copy" window disappears simultaneously with the moment when the flash drive indicator stops blinking.

Good.

Is it worth implementing this as a fix for common Puppy distros? Or is everything fine in other variants?

This has nothing to do with the distro. I don't even think that it is worth to implement at all because you are essentially crippling the functionality of the cache. It exists for a reason. If you implement the "fix" and copy a huge file from the command line, you will not get the prompt back until the data are physically written to your target device. Without the fix you will get the prompt back quickly and can perform other tasks. The OS will then write the data whenever is is appropriate.
You *could* easily restrict the fix to ROX-Filer copying but ...hmmm ... I don't see the point.

If however you feel that the fix is important to you, you should consider to do the same for the mv command. Here you should be especially careful with the creation sequence as ROX-Filer uses mv also for renaming.

[Grey]

for the mv command.

Not a problem. I only copy to a flash drive, don't move anything