Hello folks!
I have the following problem:
Whenever I try to save a datafile using the dat utility or the grabber, it crashes.

Also the grabber doesn't shut down properly whenever I run it: I just start it, select "File->Quit" and there comes a Windows-message about the program not exiting properly...
I have compiled the debug-version of Allegro now, using that the grabber program produces no error at shut-down.
But still, when I try to save a datafile, I get an error message:

>dat -a -t bmp -bpp 16 elevator.dat *.bmp
elevator.dat not found: creating new datafile
Inserting d:\prog\shdw\objs\ELEVATOR\FLY_0001.bmp -> FLY_0001_BMP
Inserting d:\prog\shdw\objs\ELEVATOR\PROP.bmp -> PROP_BMP
Inserting d:\prog\shdw\objs\ELEVATOR\STILL.bmp -> STILL_BMP
Writing elevator.dat
Assert failed at line 2300 of src/file.c

This is about line 2300 of src/file.c:

I'm running Allegro 4.2 on Windows XP.

edit: Forgot to say, there is no file saved, which is my real problem

Does anyone have any clue?
Thanks!

Do you have write permission in the target directory? What happens if you run as root (or whatever the Windows equivalent is called)?

Aaaah! With administrator-privileges, it does write the datafile, thanks!

But I certainly do have permission to create/write files in the target directory.
I forgot to mention, when I don't log on as administrator, there is a file created that has 0 bytes. So when there is a file created, why do I need administrator-privileges to write into it?

I don't know, but I've seen this same issue come up before. I don't remember what causes it, but maybe a forum search will help you.

Well, yes.
I found this thread:
http://www.allegro.cc/forums/thread/454214
However the actual cause of the problem is not got rid of by using that fix- I am on an NTFS drive, of course, so it's the same problem...
It's strange, everything but just the grabber and dat-utility works on NTFS?

Can you run dat through a debugger? If you see why the assertion is being triggered that would possibly lead you to the source of the problem.

I tried to do that, but my debugger keeps crashing. I'm using Insight, which is more or less a graphical frontend for gdb, I think. Does anyone know another working debugger for MinGW? (except for gdb, but if there is none, I could also try that)

I found the bug, but I don't have time to fix it. If someone could fix it, that would be great. Here is the problem: there is a call to pack_fopen_chunk() in datedit.c that fails. Due to some sloppy coding, this was not checked. pack_fopen_chunk() is implemented by opening a temporary file so even if you have write access to the target directory it could fail if you don't have write access to the directory for the temporary file (I think it is the current directory). Someone needs to fix pack_fopen_chunk().

In the meantime, I will apply a patch so at least dat and grabber will return a failure code rather than aborting.

Patch for pack_fopen_chunk() attached. Someone please test it in Windows, since I forgot to do this. It works fine now in Linux, but the code used in Windows is slightly different.

I'd check it, but I've never had problems with grabber under WinXP (and I use NTFS).

I have a problem with the following part:

         do {
            size = new_size;
            tmp_dir = realloc(tmp_dir, size);
            new_size = GetTempPath(size, tmp_dir);
         } while ( (size > new_size) && (new_size > 0) );

GetTempPath returns 0 on error. If that piece of code is trying to increase the buffer size to try again, it is not doing so. However, even if it does, it is possible that the temporary directory could not be retrieved, thus creating an infinite loop draining all memory. I would remove the while cycle; after the loop it is checked if it could not be extracted.

It has nothing to do with WinXP - it has to do with trying to create a file in a directory where you do not have write permission (so I was also able to reproduce it in Linux as well).
Go to a directory where you don't have write permission, start the grabber from there and safe a datafile in a directory where you do have write permission. The grabber will then try to create a temporary file in the active directory, where you don't have write permission, and crash.

That's why there's a && (new_size > 0) in there.
The code should run until it either fails or retrieves the directory after a couple of iterations.

Oh, didn't read the second part, the one saying it would return only the size

Since it returns the size in TCHAR, it may have problems with unicode (can Allegro be compiled in a Unicode project in MSVC?). Maybe it would be safer to multiply sizes with sizeof(TCHAR)? If not, dismiss that