Bug 11128 - Intermittent failure to save file *contents* to SD card.
Summary: Intermittent failure to save file *contents* to SD card.
Status: RESOLVED NORESPONSE
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 4.5.x
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-03-13 14:35 UTC by Jason
Modified: 2013-12-05 18:35 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
It would be awesome if you noted that 'description' is *required* when attaching a file. (27.49 KB, text/plain)
2013-03-13 14:36 UTC, Jason
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NORESPONSE

Description Jason 2013-03-13 14:35:07 UTC
Hardware: 
  Laptop: HP Pavilion G6, Windows 7
  Tablet: ASUS Transformer TF-101

Context:
  The application writes an XML file that is used to update a database on the laptop.   The file in question is saved to the hard drive of the tablet (as a means of backup), and then to the SD card.

  It's sneaker-net: run the activity on the tablet, save the file, remove the micro SD (the activity still open on the tablet).  Then the micro SD card is inserted into its adapter and inserted into the laptop.  The user runs an application that imports the XML file and then deletes it from the SD card.

  The card is returned to the tablet, after which the process can be repeated.  The code that saves the file is very simple: it composes XML from the Android activity's interface, then saves the result using a brand-new GUID as a file name.  It's worth noting that if the user opts to do so, they can save to the card, then move the SD card, then re-insert it and save again after making changes on the UI.  So the activity can be running for more than one cycle of edit-save-remove-import-reinsert.

The problem:
  At least half the time, the file is created on the SD card, but has no XML in it.  The same file on the hard drive of the tablet DOES contain data.  You can see my conundrum.

I've attached the code, along with some of the debug log.  

The code reflects my most recent attempt at making this work: rather than making two separate calls to the function that writes the file, I opted to write it to the hard drive, then copy it to the SD card.  This hasn't changed the behavior I'm observing; it's still an empty file just as frequently.
Comment 1 Jason 2013-03-13 14:36:23 UTC
Created attachment 3602 [details]
It would be awesome if you noted that 'description' is *required* when attaching a file.
Comment 2 Miguel de Icaza [MSFT] 2013-05-23 16:01:53 UTC
Did the catch ever produce an error?
Comment 3 Jason 2013-05-23 16:13:03 UTC
Nope... it just continued to write an empty file.
Comment 4 Miguel de Icaza [MSFT] 2013-05-23 21:55:01 UTC
What I mean is that there is a catch and the exception is being discarded, I wonder if you could print the contents of that exception?

Second, would it be possible to perhaps introduce two assertions to the code:

1. That there is data to write
2. That the data written was more than 0 bytes (check the file after the flush there)
3. Reading the data back, and comparing with the other file.

Just to rule out race conditions, overwritten files from threads, that sort of thing.
Comment 5 Jason 2013-05-24 09:29:16 UTC
I might be able to test that in the next week or so, but the app is now completely dormant.  We used it in a FIRST Robotics competition, which is now over...

I'll take a look at it next week, and try to implement your suggestions so we can get to the bottom of it.  I'll keep you posted.
Comment 6 PJ 2013-11-19 17:05:32 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 7 PJ 2013-12-05 18:35:58 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.