Format error: The volume label is invalid. #1352
Assignees
Milestone
Comments
|
Having same issue here, as well as Here's the log. 3.5 Working correctly. |
|
@InstantAli3n, please see #1351 for the Therefore, unless you can prove that these two issues are directly related (NB: It's not because they don't seem to be present in 3.5 that they are), this thread will ONLY focus on the This being said, and that applies to both you and OP, what happens if you try Alt-C or unplug/replug the drive? |
|
If the stick is to boot from uefi W10 it can be formatted ntfs. At least
with KDE 19.04 neon plasma dev or Mint 19.04 cinnamon... it is booting
correctly wit Rufus 3.5
|
|
@bjpafa, I'm not sure what you are commenting on. Are you trying to format a drive As a Super Floppy Disk (like OP does) and encountering a Also, I don't understand at all what you mean with the above. You need to indicate what options you used in Rufus, rather than what you created the USB for, which practically tells me nothing, since it doesn't tell me if you partitioned it MBR or GPT. I appreciate the willingness to help here, but, unless you provide a log, that details exactly what you tried to accomplish in Rufus and that shows an explicit Also, once again, I would really like to hear what happens if you plug/unplug the drive or try Alt-C in Rufus to cycle the USB port. |
|
Sorry for the delay, I tried again, used Alt-C (which doesn't work since I'm still on Windows 7) and then proceeded to try all 3 Partition Schemes with the same results. Happens exactly the same regardless of USB drive and unplugging/replugging. Following is the full log: |
|
Try Alt-Z then, let it zero the drive for a while then cancel, and retry after unplugging and replugging the drive. |
|
Did as asked, same results. Following is the log: |
|
Here's another log with both a different drive and port: |
|
I know you mentioned that you tried other partition schemes, but why do you seem to insist on partitioning the drive as SFD (Super Floppy Disk)? First of all, it's only available as an advanced option, and I currently know of only one case where one absolutely needs to use SFD rather than MBR or GPT. One. So can you please explain why you want to use SFD? If not, then please make sure to only test with GPT or MBR partitioning. Also, since according to Windows, the problem is with the label choice, what happens if you try to change the label in Rufus? |
|
The partitioning doesn't actually matter to me, was just using that option because I could. Using the default assigned label (for this drive "29.5 GB" without the quotes), the format completes fine. When trying to not have any label set (blank label field), it seems to be treating it as if there are too many characters getting converted to underscores (__________ fails as expected). Any label that doesn't produce too many underscores works fine. Following is a log where I did exactly that (i.e: "29.5 GB", "", "__________", and "NO_LABEL" respectively and without the quotes): |
|
Also, whenever it states |
Aha, at least we are getting somewhere.
If you are talking about the So that note about the label being underscore is not indicative of an issue. Especially, we very much sanitize the label before we apply it (make sure it's 11 characters or less, with all characters being ones that FAT support, which is the precise reason you are seeing a notice about underscores in the first place, as it is issued during label sanitization), so it should be a matter of Rufus not properly sanitizing the label for FAT32. As a matter of fact, no matter what I try, I am unable to replicate the issue, whether I use a blank label, one with plenty of underscores and so on... Even when I'm getting the message One possibility is that it might be a Windows 7 vs Windows 10 behaviour, so I'll try to test on Windows 7 when I have a chance. However, by all accounts, it seems that, in your case, the issue is the result of trying to apply a "weird" label, which therefore I don't expect should affect that many people in the first place. Of course, I'll see what I can do to fix it, but it's not as high a priority as I thought it might be. Do you have the possibility to test on Windows 10 (or on a different machine) to see if you can replicate the same issue there? Considering that my testing shows that there is an environmental component (in other words it's not programming issue that will consistently produce the same behaviour regardless of your Windows environments), I'm still going to need more details about your testing conditions before I can even explore the possibility of a fix. |
|
For the record, for all who wonder, the In other words, when Rufus formats a FAT32 drive, it basically tells Windows (through the In this case This is why I will need to get confirmation of:
|
|
Unfortunately I cannot test it on Windows 10 or another machine. It could be a Windows 7 issue, although the previous version of the program worked fine. The specific label I'm trying to apply is no label at all. (empty It also doesn't seem to be falling back to setting the label as the size of the USB. |
|
Upon looking through the code, is it possible that the |
Nope: // Convert the empty string too
if (str[0] == 0)
return calloc(1, sizeof(wchar_t));Besides, again, if this was a straight code issue, then I would be able to replicate the problem on Windows 10, which I can't (empty label works just fine for me. No error whatsoever). But are you saying that you are seeing the |
|
That is exactly what I'm saying. EDIT: I'll see if I can replicate the problem in a Windows 10 VM through VirtualBox. (May be a while) |
No need. I have now been able to replicate the issue in a Windows 7 VM. And the nice thing is I could test the exact same drive for both Windows 10 and Windows 7 (since the Windows 7 VM was being host by the Windows 10 machine). And of course, both cases were tested using the exact same version of Rufus (3.6 release) Windows 7 does indeed produce Now of course, I can also confirm that Rufus 3.5 seems to be fine on Windows 7, which gives me an idea of where to look. But the underlying problem is that Windows 7 is stricter with the kind of volume labels it accepts compared to Windows 10. Now, IIRC, I think I may have modified the label sanitization process from Rufus between 3.5 and 3.6, so that it would also accommodate Linux |
|
Okay I've cancelled my VM. While I was waiting for it, I started trying every filesystem that can be formatted on my machine.
Labels used: blank, Full log: |
|
Okay, I should have a fix now. The root of the issue is that we change the readout of the label from the User Interface from Which means that our implementation of Now, while this is a bug that obviously needs to be fixed, it still didn't matter that much if you used MSVC to compile the app, regardless of the platform, or even MinGW on Windows 10, as, in these scenarios, the executable would have set the label string to be all zeroes anyway (automatic local variable initialization by the compiler), so, even if the code didn't properly set the variable to the empty string, the compiler already took care of that anyway, so you still got what you expected. The problem however is, if you are compiling using MinGW (which is how the release version of Rufus is built) and running the app on Windows 7, then local function variables are not initialized to zero, but contain whatever garbage exists in memory. And most of the time, this will contain low level ASCII characters, which we don't eliminate as part of our label sanitization (because, sanitization is meant to apply to elements that people might rightfully try for not knowing better, such as accented characters, lowercase or So, I'm just going to point out that the Oh, and with regards to |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.Issue description
Setting a blank label produces an error and the format fails.
Log
The text was updated successfully, but these errors were encountered: