Copying/cutting files DANGER

HI. I have got a second issue.
When I copy or cut and paste a file into an USB NTFS format, it appears a progress bar. Ok, BUT when it ends and take off the USB stick I put it in again and the usb is corrupt or no file appears. The same when I delete them from USB. System says it is deleted but if I take off USB and put it in again, the same two things can happen: or USB corrupt or the file is still there.
The only way to make it work OK is to click on Take device off with safety. Then everything goes ok. It happens to me with some Linuz distros too, not just this.
It is dangerous that you put a file into an USB at work and then you realize that it is none, your work lost, or USB corrupt.
Salutes.

I would always unmount your drives before just pulling them out. From my memory NTFS were notorious for having issues when not unmounted safely. Sounds like it may not have changed.

2 Likes

Yes, this is the secure way to keep files saved and ok. I thought it was for any lack in kernels or so. This is a very dangerous thing if you trust in progress bar and just pull usb out. Thanks.

That’s because this IS the only right way to remove an external device.

When the progress bar ends, this doesn’t mean that the file is already completely saved on the USB drive. If your drive had an activity LED, it would probably still be active for some time in order to completely write the file to the drive (I guess from some sort of drive cache).

So ALWAYS use the Safe remove option, nothing else.

1 Like

especially when going from one file format to another as permissions are handled differently along with read write speeds USB device type 2 or 3 to name a few lol.

If you are not sure you should

sync; sync

before you pull it out. sync is a non-blocking operation but if you call it twice it will have blocking behaviour and it will clearly indicate when the write is done.

Because copy is done quickly into a temporary memory (buffer) of the hardware and sync will force it to write into the permanent memory (which may be slow). When you unmount the drive or properly shutdown the computer it will sync automaticaly.

2 Likes

Ok. Thanks.

Interesting. Is that documented somewhere? I don’t see anything to that effect in the man (whether section 1 or 2).

gnu sync

The sync program does nothing but exercise the sync, syncfs, fsync, and fdatasync system calls.

It is based on linux sync() function.

   According to the standard specification (e.g., POSIX.1-2001),
   sync() schedules the writes, but may return before the actual
   writing is done.  However Linux waits for I/O completions, and
   thus sync() or syncfs() provide the same guarantees as fsync()
   called on every file in the system or filesystem respectively.

According to the documentation - the sync always waits for I/O completion before returning (at least on linux system).
I am not sure if I/O completion is just a disk cache (which is lost on power failure) or non-volatile memory.

I am not exactly an expert on this field but I base in on my observation.
When I copy large files to a flash drive a single sync returns almost instantly but the LED on the drive is still blinking.
On the other hand when I run sync; sync command it blocks the terminal before all the writes are done (several minutes) and when the command returns the light on the drive is blinking no more.
When you call sync and there is nothing to write to the disk there is no practical load on the cpu so the second sync is not an issue in my opinion.

2 Likes

Yep, what you quote is the man section 2 (system calls) that I mentioned in my previous post; I didn’t find any language in here that matched the behaviour you described, which is why I asked whether it was documented.

The way I read it, it should be blocking on every call:

[under linux] the same guarantees as fsync()

From fsync (2)

The call blocks until the device reports that the transfer has completed.

Anyway, observation trumps documentation that one is unsure one understands. I have an annoying mp3 player that rsyncs instantly but then takes forever actually doing the writes; I’ll be sure to use it as guinea pig for a bit of sync; sync testing. Thanks for the tip.

1 Like

In the last 2 weeks is have used sync a bunch with different USB keys, and a single call is always blocking for me :woman_shrugging: