Hello,

this must be some stupid mistake, tho i can't figure out why it's failing always

invoke CreateFile, addr FileName, GENERIC_WRITE, FILE_SHARE_READ, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_ARCHIVE, NULL
cmp eax, INVALID_HANDLE_VALUE
jz @logfailed
.
.

calling CreateFile in debugger always invokes interrupt, passing to program returns 0xFFFFFFFF.

running the program without debugger even terminates the callee program...

<FileName> doesn't exist but path is valid. Tried also C substitutee _open() but same result ( _open is just frontend for CreateFile).
What's wrong with it? I checked many sample sources but thy seem to create files the same fashion.

thanks for any input.
servil
Posted on 2003-03-07 15:29:36 by _Servil_
Everything seems fine to me. Are you sure FileName is a valid string? You are also testing for zero. Shouldn't you be testing for INVALID_HANDLE_VALUE?
Posted on 2003-03-07 17:36:24 by Odyssey
GENERIC_WRITE, FILE_SHARE_READ


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp


FILE_SHARE_READ Enables subsequent open operations on the object to request read access. Otherwise, other processes cannot open the object if they request read access.

If the object has already been opened with read access, the sharing mode must include this flag.
FILE_SHARE_WRITE Enables subsequent open operations on the object to request write access. Otherwise, other processes cannot open the object if they request write access.

If the object has already been opened with write access, the sharing mode must include this flag.


maybe it flips on this?
Posted on 2003-03-07 18:01:04 by Hiroshimator
I agree with Odyssey that the syntax seems OK. The only unknown is the file name which you did not submit for checking. You maintain that the path exists. Have you tried to use only the file name without any path (i.e. to create it in the current directory) to see what happens? Is the string also zero-terminated?

The return value of -1 is the equate value of INVALID_HANDLE_VALUE. I "assume" that your handling of that case with the jump to @logfailed is probably responsible for terminating the program when you run it without the debugger.

Raymond
Posted on 2003-03-07 20:02:32 by Raymond
Hello,

unfortunatelly it seems be not so straightworward as sugested, the path exist file no, simple CTXT("logfile.txt") or something similar makes it fail too. And as well if all access rights are set and no sharing allowed.

And no, the prog terminates not due to @logfailed but during this call. Strange the RaiseExceptionDispatcher(...) API with debug break is invoked during this so I'm able to pass thru only with debugger, it returns 0FFFFFFFFh in EAX. GetLastError() gives ERROR_PATH_NOT_FOUND (00000003) but should be ignored on CREATE_ALWAYS? hmm something fishy - is happening on NTFS volume, should do matter? Process under admin rites and full R/W access in run folder..

servil
Posted on 2003-03-08 10:09:54 by _Servil_
This gives the impression that your system is set up to terminate any program trying to write to wherever you are attempting to (more or less like an anti-virus program).

The debugger can bypass some of the features but your system is still able to return a "no-path" error code, thus preventing any opening of a file for writing (the CreateFile fails when the path is not found).

If you are on a network, the system admin may be the source.

Raymond
Posted on 2003-03-08 10:34:38 by Raymond
Hi,

This is a local drive, I'm logged under my name as member of admins group, and admins group has full access, including administrative rites to the folder. This is the account under what debugged program runs.. So if I do a dumb text in notepad and save there it makes no problem. Also if I replace filename in my source to FAT drive it succeeds.

Most probably it will requires some additional treatment...

servil
Posted on 2003-03-08 11:11:10 by _Servil_
I think FILE_SHARE_WRITE should be used instead.
Posted on 2003-03-08 20:22:01 by roticv
I just tried it on Win2K with an NTFS drive (admin privledges) and it worked fine exactly as it's typed. I would suggest you check your privledges as you may not have access privledges to the root path or to create files/folders. Try including a full path in the filename that you are sure you have access priveledges to.

Donkey
Posted on 2003-03-09 23:56:46 by donkey

I would suggest you check your privledges as you may not have access privledges to the root path or to create files/folders. Try including a full path in the filename that you are sure you have access priveledges to.


I tried it and checked before posting this. It's probably NTFS issue, but I can't find the cause since as I wrote I have full admin rights to project folder (to whole volume). I can freely do any file operations in project folder - but not with the app self. Also I tride to create in root, the same result (I'm set to be the owner as well).

The Security_desriptor arg left as NULL - I'd assume for NULL values OS should assign rites inherited from folder or nearest folder in structure having not inherited rites so this is treated (?)
Posted on 2003-03-10 15:40:28 by _Servil_
Please post your file path string code and sample string for analysis.

Or try your string in this code.

Working code snippet:

mov Timeout,100 ;Makes 20 seconds / 100 trys before aborting file write.
ReTryWrite:
invoke CreateFile,
ADDR szEPathFileName,
GENERIC_WRITE,
0,
NULL,
OPEN_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL
.if eax == INVALID_HANDLE_VALUE
invoke Sleep,200 ; .2 seconds for a retry.
dec Timeout
jz @F ;OK, so just give up.
jmp ReTryWrite
.else
mov hErrorFile, eax
.endif


Regards, P1
Posted on 2003-03-10 15:55:15 by Pone
Thanks your source finally helped to locate.
Calling CreateFile on NTFS volume with direction flag set invokes exception (API bug?)

servil
Posted on 2003-03-11 18:04:37 by _Servil_
Not a bug, but an undocumented requirement.
The HLL compilers take care of this. There is no official ASM level documentation.

When you call an API, the direction flag, DF, must be cleared.
Also, in your callbacks (for example, WndProc), DF must be cleared before you return. DF will be cleared when your callback is invoked, so if you don't change it, it will be OK.
Posted on 2003-03-11 19:55:04 by tenkey