• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

[BUG] Rip to ISO 'NUL' file

Status
Not open for further replies.

0x0x0x0x0

Well-Known Member
Thread Starter
Joined
Sep 21, 2020
Messages
1,326
Likes
591
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
 
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?
 
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?


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 ;-)
 
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.
This isn't a bug. Let's call it a "feature request".
 
James was being a little sarcastic there :p

Sent from my Pixel 3 XL using Tapatalk
 
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.
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.
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 ;-)
As I said, it could be useful as a new feature. That's why I still like HDDs.
 
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.


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?

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.

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!

As I said, it could be useful as a new feature. That's why I still like HDDs.

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.
 
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)
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.
 
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.

I didn't complain about 'NUL:', I complained about 'NUL.iso'
 
But NUL:, NUL, NUL.iso and NUL.anything all equate to the NUL: device in Windoze.

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:

Code:
#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);
    HANDLE OutH = CreateFileA(path, GENERIC_READ|GENERIC_WRITE, 0, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0);
    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);
                break;
            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;

error:
    fprintf(stderr,"\t... that didn't go well: GetLastError() returned 0x%x...\n", GetLastError());
    return 1;
}

which produces

Code:
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:
All true, but it still isn't a "bug", as it isn't supposed to work. It is a nice feature request.
 
All true, but it still isn't a "bug", as it isn't supposed to work. It is a nice feature request.

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).
 
Status
Not open for further replies.
Back
Top