Not a new user, but I'll post here anyway __{{emoticon}}__

I never thought anything would get me off rox, but I've been playing around with spacefm and I'm really liking it. I'm working on some configuration tweaks to make things easier on me. I do have a question though about large file transfers (to usb storage for instance. )

By default the system (whether using rox or spacefm) dumps the file to a write-buffer and then goes on its merry way. I've got some large files (ripped movies) that have taken about 8 minutes after rox and spacefm think they are done to finish writes. this is only obvious when you try to eject the usb drive. neither rox nor spacefm give you any indication as to why the eject doesn't work, until 8 minutes later then the write finishes and the eject goes through. This actual happens the way I think it should when writing to a network share.

I'm wondering is there a tweak that would allow the file-copy progress bar is spacefm to reflect the actual writes?

I'm probably being as clear as mud here.

I don't know if it is the same issue, but I have noticed that when I use dd to install to a usb-stick, it seems like it is done, but it is not.
I have to wait a while longer, and when the little led (that I am happy my stick has) stop flashing, it really is done.

As I said, I am not sure if it is the same issue, but maybe?

I'm sure it is. I believe it has to do with the mount settings, but I've been playing around with sync and async and I'm not seeing a big change. It became an issue this morning with my phone, which has no blinking activity light. Moving a 1.6 gb movie took about 11 minutes, although the progress bar in spacefm reported about 1.5 minutes. Until I ran the eject command, I didn't know it wasn't done, and it took so long to eject I thought the program crashed. I actually ended up with a corrupt file as a result. Its workable now that I know about it, but its non-intuitive to say the least. I hate to say it, but a more"windows" like behavior may be beneficial for removable media.

I have noticed this to be a problem as well, unfortunately I have not solution worked out (it has not bothered me to much)
Maybe this will help?

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://wiki.archlinux.org/index.php/Xfce#Non_ASCII_characters_when_mounting_USB_sticks"
linktext was:"https://wiki.archlinux.org/index.php/Xf ... USB_sticks"
====================================


I seem to recall a place in spacefm that will allow the inclusion of mount options ( i do not remember exactly where at the moment), so maybe it would be better to add it there rather than fstab.

Thanks for the link.

I had not seen flush before. So here's a summary of spacefm behavior with different link options.

1. with sync, the progress bar stays up 1 to 1 with the copy, but its amazingly slow.
2. with flush, the progress bar fills rapidly but the command stays open, with the elapsed time still counting up. About 6 minutes to move a 1.6gb file.
3. with no option specified (async is the default I think in spacefm), the bar fills up and the command disappears from the task window. The copy is still happening and will finish if you do an unmount or an eject/remove operation.

I've added flush+vfat to my mount options in spacefm, which will leave all mounting to the default except for vfat filesystems, like most usb thumb drives.

since udevil controls the automounting of usb keys in antiX, I also added"flush" to the vfat default options in udevil.conf.

**edit** similar behavior in rox. the copy command window stays open through the copy now.

Was reading that Brasero and K3b have similar issues writing to USB,
may not be a file manager issue

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.tuxradar.com/answers/610"
linktext was:"http://www.tuxradar.com/answers/610"
====================================

EXT2

The reason USB keys and flash memory cards are formatted with FAT as standard is that everything can read and write FAT. Manufacturers of these items are less concerned with using the most effective filesystem than making sure it works for everyone. Having said that, you can use almost any filesystem you like on a flash memory device. You should steer clear of journalled filesystems, like ext3, ReiserFS, XFS and NTFS because the journal can severely reduce the life of the device. Flash memory can only accept a limited number of writes to any one location (most manufacturers quote 100,000). A block that is written to every time anything on the filesystem is changed will be subject to much heavier wear and will fail far sooner than the rest of the drive.

HFS+ filesystems are supported in Linux, although with limited journalling support, which is a good thing for the above reasons but is also a reason to not use HFS+ on memory sticks on a Mac. Ext2 is a good choice as it is fast, reliable and non-journalled. It is also supported on other operating systems, but not by default. There is an ext2 driver for Mac OS X available from
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://sourceforge.net/projects/ext2fsx"
linktext was:"http://sourceforge.net/projects/ext2fsx"
====================================
and one for Windows from
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.fs"
linktext was:"www.fs"
====================================
driver.org. Is your ext3 filesystem actually read-only, or simply not writeable by your user? The output from mount will show this - it will contain 'ro' if mounted read-only. Otherwise, it is likely that, as the filesystem was created by the root user, it is owned, and only writeable by, root. To fix this, mount the stick and run

Just throwing this in here, cuz of the thread title.


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.commandlinefu.com/commands/view/1868/watch-the-progress-of-dd"
linktext was:"http://www.commandlinefu.com/commands/v ... ress-of-dd"
====================================



========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.cyberciti.biz/faq/linux-unix-dd-command-show-progress-while-coping/"
linktext was:"http://www.cyberciti.biz/faq/linux-unix ... le-coping/"
====================================

@bbwf - yes, the behavior is a feature, not a bug, of the underlying file system and the way the write-caches are handled by underlying system. i haven't tried it, but I imagine the behavior would be the same no matter what the filesystem on the removable device. all of my removable media is fat32 already, and that's fine with me. android phone is the same way. keeps things universal, as the article you referenced says.

For the copy large files I use
ssh and
scp.

Example:
Data partition with pictures, music, videos, documents ...
Size 17 GB
from laptop to desktop
Duration 26:25 Min

Back see man scp
-r
-p
-v

voila __{{emoticon}}__