Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#8 size matters

1.0
pending
Jeff B
None
2014-04-17
2014-03-07
Haihong
No

1st I must say, I am a huge fan of this tool, saving my days again and again.

Currently v0.9 (and other variants) still blocks the image write back, if image size indicates smaller than current CF/SD card. This is the only draw back that I feel important to fix.

This is a problem for embedded system developers/admins (who I believe use this tool more often than others) when different brands/models often have their sizes tens/hundreds of MB different. E.g, Kingston even have two generations of 4G CF cards of different sizes.

I believe we all want the warning/err dialog box to have an option to continue, to force restore/clone to smaller card. Then we can work on our own work flows, ensure we only partition CF/SD card to use only a reduced size (say put partitions in first 3.4G instead of full 3.8/4G of whole card), by reserving a tail zone of unused. Then this restore/clone allow developers just to cater for card variants, say a Android devel 8G img maybe should contain only 7G useful partitions, but then applicable to all 8G variants SD/microSD models available.

Gotta say, with this feature in, it's already perfect 1.0 for me.

1 Attachments

Discussion

  • Haihong
    Haihong
    2014-03-07

    sorry, forgot to put what I hope to have:
    before or when this dialog pops, allow me to choose whether I want to force continue to write img to card, based on smaller size, rather than totally block. Then I only need to ensure last 100~200 MB of source card before img creation is actually not partitioned/used.

     
  • I am hoping for this feature as well. I found another utility called SDImager here and I tried it yesterday and it does not verify before writing if the new card is smaller than the image. When it gets to the end of the writing process it throws an error but in fact the card is written with the data from the image and seemed to work fine for me.

    I'm hoping that this utility can be improved to check for card vs image size and then if it is close ask if you want to write as much as the card will hold. Perhaps the last sectors that do not fit could even be checked to confirm that they do not include any data?

     
  • Tobin Davis
    Tobin Davis
    2014-03-29

    Ticket moved from /p/win32diskimager/tickets/11/

    Can't be converted:

    • _importance: High
    • _windows_version: 7(64bit)
    • _milestone: 1.0
     
  • Tobin Davis
    Tobin Davis
    2014-03-29

    Moved to Feature Requests, as it is not really a bug. Status is unchanged (in my view). Still targeting for 1.0 release.

     
  • Tobin Davis
    Tobin Davis
    2014-03-29

    • status: open --> accepted
    • assigned_to: Tobin Davis
     
  • Jeff B
    Jeff B
    2014-04-10

    • assigned_to: Tobin Davis --> Jeff B
     
  • Jeff B
    Jeff B
    2014-04-10

    commit 7d6f3a contains the changes for this feature.

    I simply added a warning dialog that tells the user that there isn't enough space to hold the entire image, but allows them to continue with the write if they choose to. If they do choose to continue, the computed size of the image is truncated to match the computed available space.

    I only implemented this on writes, as reads will write to a fixed drive, and filling a fixed drive to the brink is never a good idea.

    An improvement to this would be to read the data that would be truncated and attempt to determine if it's empty, warning the user if data is found. I wanted to get this initial cut in though, in case I don't have time to implement that functionality.

     
  • Jeff B
    Jeff B
    2014-04-10

    • status: accepted --> pending
     
  • Jeff B
    Jeff B
    2014-04-15

    commit 72f2b29 contains the change to examine the truncated data and notify the user as to whether it appears to contain any actual data.

     
  • Jeff B
    Jeff B
    2014-04-17

    commit c3f4f37 adds an error check when reading the "truncated" data, and adds a slight optimization when verifying whether it contains any actual data.