[BUG] Rip to ISO 'NUL' file

Discussion in 'AnyDVD HD (Blu-ray issues)' started by 0x0x0x0x0, Oct 26, 2020.

Thread Status:
Not open for further replies.
  1. 0x0x0x0x0

    0x0x0x0x0 Well-Known Member

    Sometimes you just want to read the disc to make sure it is defect free without actually saving the contents of the thing. Windows has a special file name called NUL that automatically discards whatever is written to it [1]. When NUL.iso is given to AnyDVD (in any form: 'NUL', 'NUL.iso', 'c:\NUL.iso'), AnyDVD does weird stuff trying to resolve that and eventually fails to use it properly. It would be great if AnyDVD supported it.

    1. Naming Files, Paths, and Namespaces
  2. el Filou

    el Filou Well-Known Member

    Writing to NUL can't work as an ISO is an image of a filesystem, not just a stream of bytes of unstructured data. Also the article you linked to literally says not to use NUL or NUL.* as an output file.

    Checking a disc without actually ripping it could be useful, but it's easy to just rip to TEST.ISO and delete it afterwards, is this a disk space issue?
  3. 0x0x0x0x0

    0x0x0x0x0 Well-Known Member

    Read the article again and why it says not to use NUL (or its variations) as a general output file name (hint: because the contents will be swallowed up by the Windows kernel!) You might also want to look through stackoverflow for questions about Windows and NUL filenames.

    Even if AnyDVD isn't writing linearly but is seek()ing within the file for writing, I don't see why that would be a problem. The special existed since the old days of CP/M and never caused a problem if the applications just open the file normally and not try to do weird stuff.

    Why would anyone want to not dump the entire 50--100GB of content data to an SSD at a time just to check integrity of the media? I wonder ;-)
  4. James

    James Redfox Development Team Staff Member

    This isn't a bug. Let's call it a "feature request".
  5. 0x0x0x0x0

    0x0x0x0x0 Well-Known Member

  6. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    James was being a little sarcastic there :p

    Sent from my Pixel 3 XL using Tapatalk
  7. 0x0x0x0x0

    0x0x0x0x0 Well-Known Member

    I figured ;-p wasn't gonna mention the numerous outstanding "feature requests" Microsoft has in their bug-free software ;-)
  8. el Filou

    el Filou Well-Known Member

    No, the reason is NUL's purpose is for removing console output/error stream, not for opening as a normal file for random access. I've had a look at StackOverflow on your advice, and all the examples (including the one you linked to) talk about console apps.
    Just because something sometimes works like you want it to outside of recommended behaviour doesn't mean it's a bug when it doesn't.
    As I said, it could be useful as a new feature. That's why I still like HDDs.
  9. 0x0x0x0x0

    0x0x0x0x0 Well-Known Member

    You found some use-cases because that what people coming to Windows from the Unix world ask for but you didn't look at actual coding examples (note the difference between a use-case and what a "thing" does, you can even read from the NUL file, or test for its existence: What's the deal with those reserved filenames like NUL and CON); you obviously didn't stumble across How to open a “nul” file?

    That is where you are manifestly wrong: the purpose of the NUL file is to discard anything that is written to it after opening. What do you think happens when you redirect the output from a console app to it; the file is open like any ordinary file and the *kernel* discards anything that is written---there is no magic in console that automagically knows what to do with specials!

    It's not "a new feature" request but a bug because the program behaves contrary to how it is supposed to (at the system level) by doing whatever it is doing with destination file names, instead of just calling CreateFile() with whatever is given by the user and either failing or succeeding. What you are proposing (writing to an HDD) is a work-around to a problem created in software, not a solution.
  10. James

    James Redfox Development Team Staff Member

    Absolutely not. AnyDVD does various checks, like "will the file fit to the destination". It checks, if the filesystem can cope with files > 4G. To improve performance it does special calls to the filesystem. And so on. All this stuff won't work with NUL:, which is a streaming device.
  11. 0x0x0x0x0

    0x0x0x0x0 Well-Known Member

    I didn't complain about 'NUL:', I complained about 'NUL.iso'
  12. BrianG61UK

    BrianG61UK Well-Known Member

    But NUL:, NUL, NUL.iso and NUL.anything all equate to the NUL: device in Windoze.
  13. 0x0x0x0x0

    0x0x0x0x0 Well-Known Member

    Really? What on Earth gave you that idea???

    Right, since as some who have patently never heard of the NUL files are trying to tell someone who's been programming for about 30 years that I'm "doing it wrong," here's a trivial console app to disabuse you of that notion:

    #include <stdio.h>
    #include <Windows.h>
    BOOL WriteStuff(HANDLE h) {
        const char buffer[] = "123456";
        DWORD written = 0;
        return WriteFile(h, buffer, sizeof(buffer), &written, NULL);
    int main()
        const char path[] = "c:\\nul.iso";
        fputs("Creating file...\n", stderr);
        if (OutH == INVALID_HANDLE_VALUE) {
            goto error;
        if (GetLastError() == ERROR_ALREADY_EXISTS) {
            fputs("\t...file was already present\n", stderr);
        LARGE_INTEGER size;
        size.LowPart = 0;
        size.HighPart = 500;
        fprintf(stderr, "Setting file pointer to %lld bytes...\n", size.QuadPart);
        if (SetFilePointerEx(OutH, size, nullptr, FILE_BEGIN) == 0) {
            goto error;
        fputs("Setting file size...\n", stderr);
        if (SetEndOfFile(OutH) == 0) {
            switch (GetLastError()) {
                case ERROR_INVALID_FUNCTION: /* NUL files are limitless*/
                    fputs("\tNUL files are limitless...\n", stderr);
                default: goto error;
        fputs("Writing some stuff at the current file pointer...\n", stderr);
        if (WriteStuff(OutH) == 0) {
            goto error;
        fputs("Rewinding to start of file...\n", stderr);
        if (SetFilePointerEx(OutH, {0}, nullptr, FILE_BEGIN) == 0) {
            goto error;
        fputs("Writing some stuff at the new file pointer...\n", stderr);
        if (WriteStuff(OutH) == 0) {
            goto error;
        fputs("We are done!\n", stderr);
        return 0;
        fprintf(stderr,"\t... that didn't go well: GetLastError() returned 0x%x...\n", GetLastError());
        return 1;
    which produces

    Creating file...
    Setting file pointer to 2147483648000 bytes...
    Setting file size...
            NUL files are limitless...
    Writing some stuff at the current file pointer...
    Rewinding to start of file...
    Writing some stuff at the new file pointer...
    We are done!
    D:\FileNul\FileNul\Debug\FileNul.exe (process 6024) exited with code 0.
    To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.
    Press any key to close this window . . .
    on the console...

    Anyone wants to show off more of their "wisdom"?..
    Last edited: Nov 1, 2020
  14. James

    James Redfox Development Team Staff Member

    All true, but it still isn't a "bug", as it isn't supposed to work. It is a nice feature request.
  15. 0x0x0x0x0

    0x0x0x0x0 Well-Known Member

    Sure, just like in late 90s and early 00s not being able to write to any disk that was not 'C:' was not considered a bug...

    A feature request, on the other hand, would be to have a "Verify Medium" function (without any mention of the NUL file).
  16. James

    James Redfox Development Team Staff Member

    'nuff said.
Thread Status:
Not open for further replies.