User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; aff-kingsoft-ciba; .NET4.0C; .NET4.0E) Steps to reproduce: 1. Open the camera app, and take a picture; 2. Open the Gallery from the camera; 3. After open the Gallery,remove the battery when you see the picture just taken. 4. Reboot the device, Open the Gallery 5. Open the UMS mode, connect the device to the PC. The step 2 and 3 should be done in a little time. My build Info as following: gaia：f601fe6e5edb7d5016c07abfad8f069af7354f7b gecko：60d9e982e07e8d09e9d0e52bad6433c302c17f32 gonk-misc：ca9192d7ef6037016d4723647d86b72f7a410633 REPRODUCING RATE: 5/5 Actual results: 1. In step 4, we can't see the picture just taken; 2. In step 5, we can see the picture just taken, but the size of it is 0KB. Expected results: 1. In step 4, we can see the picture just taken; 2. In step5, we can see the picture just taken, and it should show the true size.
How do we feel about a picture not showing up or showing up zero-length due to intentionally yanking the battery?
That sounds like expected behviour to me. There is a small delay between writes occuring and the data actually being written out to flash. If you pull the battery before the wrrites hit the flash, then you can wind up with all types of weird situations ocurring. It's probably possible to ensure that the data is written to flash before adding the entry to the database, but this would introduce a fairly significant delay in saving pictures. We should definitely deal with the inconsistencies in a reasonable fashion. To me, I really don't think the tradeoff of making things totally consistent is worth the performance hit.
Dear Dave, Do you mean it is the design behavior? Does the picture will be shown in gallery before saved to the flash? How long does it take to take a picture(including press the camera button, show the image in gallery, and save to the flash)? Thanks.
(In reply to lecky from comment #3) > Dear Dave, > > Do you mean it is the design behavior? I don't think that there is a specification. > Does the picture will be shown in gallery before saved to the flash? Sure. The picture is written to the file system, but the filesystem may take some time to store the image to flash (several seconds, in fact). > How long does it take to take a picture(including press the camera button, > show the image in gallery, and save to the flash)? I'm not sure. The time to save to flash will depend on how much unwritten data there is currently, which filesystem is being used, and how fast the flash is. Currently, saving to flash happens asynchronously with displaying the picture on the screen. For example: adb shell dd if=/dev/zero of=/sdcard/testfile bs=4096 count=4096 will return to the shell before /sdcard/testfile is completely written to flash. I did a quick test on my unagi, and time adb shell 'dd if=/dev/zero of=/sdcard/testfile bs=4096 count=4096' takes about 2 seconds. time adb shell 'dd if=/dev/zero of=/sdcard/testfile bs=4096 count=4096; sync' takes about 6 seconds. Using bs=65536 count=3 is a bit more typical of an image, and without the sync, I see about 85 msec, and with the sync I see 130-500 msec. With the sync it would be higher if other things, like IndexedDB, were also writing to disk.
Dear Dave, Thanks for kind help. Is there the method to make the saving time shorter on HD V1.1? Thanks.
(In reply to lecky from comment #5) > Dear Dave, > > Thanks for kind help. > > Is there the method to make the saving time shorter on HD V1.1? > > Thanks. The time to save to flash is really dependent on the hardware. When saving to internal flash, the speed of the internal flash chip is whats important. And for the external sdcard, the speed of the card itself makes a huge difference. The flash drivers included in the kernel can also have an impact (for example, drivers which use DMA tend to be faster than those that dont). I believe that changing the filesystem mount options can also have an impact. For example, on most flash filesystems, disabling the writing of last accessed times oftens improves things. Other options may also benefit, but it really depends on the drivers and the flash chips.
I feel that gecko does not explicitly call flush to the file system. So, the file system might defer the flushing the task.
Would there be a performance penalty for calling flush() regularly in the camera? My point-and-shoot camera throws a little "SD card" icon onto the screen when it's writing to the SD card, to let you know it's saving your photo in the background. Perhaps DeviceStorage could provide with some "cache-is-flushed" feedback we could use to provide a similar experience? (And we could always force a flush() when the user closes the camera or switches to another app.) That is, assuming we think yanking the battery immediately after taking a picture is a valid use case.
Summary: [B2G][Helix][Camera][ouyangming]The picture taked from the camera app is not saved when remove the battery → [B2G][Helix][Camera][ouyangming] The picture taken by the camera app disappears if you remove the battery (file system caching issue)
I can reproduce this on a flame. I think the use case is extremely unlikely to happen and it's not worth the effort to work on something more robust or introducing a performance penalty when saving pictures. I will close this but I let Mike reopen it he disagrees with me.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
There's not much we can do when power goes away--especially if it goes away abruptly due to user intent.
You need to log in before you can comment on or make changes to this bug.