I wrote a file to a microSD card in a USB reader and was surprised to find that when I got it to where it was going, the file had no contents. I did duly eject the drive before physically removing it from the USB port. Later I tried writing the same file through the XP virtual machine I run in VirtualBox. It look longer to write, and again, after having duly ejected it, the file was intact this time.
Perhaps VirtualBox is slower about USB access then a real Linux machine, but it seems that when I went to eject the drive under openSUSE, it performed the ejection before flushing the write-behind cache. I thought the major purpose of unmounting USB drives in this way was to make sure the write-behind cache was flushed before telling the user he could pull the drive. Does anyone know any more about this?
I’m running openSUSE 11.4 64-bit.
On 2012-03-17 04:36, PenguinLust wrote:
>
> I wrote a file to a microSD card in a USB reader and was surprised to
> find that when I got it to where it was going, the file had no contents.
…
> user he could pull the drive. Does anyone know any more about this?
> I’m running openSUSE 11.4 64-bit.
I have not seen a problem like what you describe.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Not seeing this
But in kde, the file notification that tells you the transfer is complete, actually happens before the file is written.
Let’s say I write a 500MB file to a USB, it takes a couple of minutes before the notification tells me it’s complete, but actually I need to wait about the same time again until it is actually written and removable.
Yes, this is my observation too. sig:(
You did “eject” (read: umount) the device, but did you wait until this was confirmed? Cache has to be written.
Yes of course! KDE show the confirmed sign in the taskbar before the low level procedure complete to write the flash memory! This is the issue. Maybe a bug, I think.
I’m inclined to agree.
It shouldn’t really offer a notification of complete when it’s not. Which is what it’s doing…
On 2012-03-17 14:06, caf4926 wrote:
>
> speedygeo;2448947 Wrote:
>> This is the issue. Maybe a bug, I think.
> I’m inclined to agree.
> It shouldn’t really offer a notification of complete when it’s not.
> Which is what it’s doing…
Notice that you may be confusing two different confirmations.
One is that the file is copied, and as far as the application is concerned,
it is true. The kernel has all the data and it is still writing data in the
background, but the application has finished copying and can do something
else. This is a Linux feature.
Another is the confirmation that the device has been ejected successfully.
This is the one you have to watch out for. If this confirmation is
displayed before the kernel has finished, then you have found an ugly bug
you have to report ASAP.
It affects probably only that desktop. You should tailf /var/log/messages
on a terminal to see what is happening behind.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Just to clarify in relation to @robin_listas comment.
If I try and eject the device on the complete notification > It does not eject until the data is actually written. Which is correct.
But it’s possible the OP has seen the ‘Complete’ notification and done the eject before the writing is complete and then just pulled the USB, not realizing it hadn’t finished.
In kde 4.8 > I see improved notifications for such devices, but the mistake could still be made.
I wouldn’t have pulled the drive unless I felt I had leave to do so. If, as they say, the software is completely robust, and won’t perform the eject until the cache is flushed, then what seems most likely is that I was fast and loose about interpreting that leave to pull the drive. Perhaps the notification could have stood improvement.