Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Laptop: HP Pavilion G6, Windows 7
Tablet: ASUS Transformer TF-101
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.
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.
Created attachment 3602 [details]
It would be awesome if you noted that 'description' is *required* when attaching a file.
Did the catch ever produce an error?
Nope... it just continued to write an empty file.
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.
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.
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.
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.