1. file access again


My app does

writefile = open(writefilename,"ab") -- and open a new file 

and i get a -1. The problem is that's wrong.

I can :

  • open dosbox, type D:\ngrams\dbpedia\props3\A\Autism.txt -- prints to screen
  • open dosbox, dir D:\ngrams\dbpedia\props3\A\Autism.txt -- prints data about
  • open dosbox, edit D:\ngrams\dbpedia\props3\A\Autism.txt -- opens dos editor
  • open Textpad, open and edit and save file -- performs properly

All jokes about autism and Aspergers aside, what is the malfunction here? When Eu returns -1 as writefile, there is no data to understand whatever it's problem is.

useless

new topic     » topic index » view message » categorize

2. Re: file access again


This error happens with eui and euiw of v4.1.0.Nov28 on winxp.

junk = dir(writefilename) -- also returns -1 



But the file IS there, visable and available in dosbox and in Explorer, accessable by dos and win32 text editors.

useless

new topic     » goto parent     » topic index » view message » categorize

3. Re: file access again

eukat said...


My app does

writefile = open(writefilename,"ab") -- and open a new file 

and i get a -1. The problem is that's wrong.

I can :

  • open dosbox, type D:\ngrams\dbpedia\props3\A\Autism.txt -- prints to screen
  • open dosbox, dir D:\ngrams\dbpedia\props3\A\Autism.txt -- prints data about
  • open dosbox, edit D:\ngrams\dbpedia\props3\A\Autism.txt -- opens dos editor
  • open Textpad, open and edit and save file -- performs properly

All jokes about autism and Aspergers aside, what is the malfunction here? When Eu returns -1 as writefile, there is no data to understand whatever it's problem is.

Pardon, but if I may be helpful...

said...

there is no data to understand whatever its problem is.

(Normally, I don't care since these two sound the same, but since eukat has been so helpful in pointing out these issues in the past, I thought I'd return the favor at least just this once.)

In general, it's hard to say. If open() returns -1, that just means that fopen() returned NULL instead of a valid file handle.

On a nix system, you can check libc's errno value at this point to get more useful information (e.g. was it a permissions issue, low level i/o error reported from the driver, etc.) but I don't know if the relevant analogue applies on other platforms.

At first glance, this looks like it's happening on the same disk that had the strange errors and suspected disk corruption as referenced in http://openeuphoria.org/ticket/825.wc and http://openeuphoria.org/forum/m/119991.wc

new topic     » goto parent     » topic index » view message » categorize

4. Re: file access again

Hi Kat, can you do a print of the writefilename just before the open attempt?
Apologies if this is obvious, but its easy to have a typo of a slash intended to be a double slash etc.

Regards,
Alan

new topic     » goto parent     » topic index » view message » categorize

5. Re: file access again

eukat said...


This error happens with eui and euiw of v4.1.0.Nov28 on winxp.

junk = dir(writefilename) -- also returns -1

But the file IS there, visable and available in dosbox and in Explorer, accessable by dos and win32 text editors.

Another possibility - perhaps you've unearthed some kind of sequence corruption bug? Such that writefilename gets mangled into something that doesn't exist?

new topic     » goto parent     » topic index » view message » categorize

6. Re: file access again

fizzpopsoft said...

Hi Kat, can you do a print of the writefilename just before the open attempt?
Apologies if this is obvious, but its easy to have a typo of a slash intended to be a double slash etc.

Regards,
Alan


Yes, and i copy/paste the printed filename to attempt access in dos and Textpad. I observe the name in Eu's debugger. This is the relavant code block:

        writefilename = "D:\\ngrams\\dbpedia\\prop3\\"&linetitle[1]&"\\"&linetitle&".txt" -- open a new one 
        writefile = open(writefilename,"ab") -- and open a new file 
trace(1)                 
        junk = dir(writefilename) -- see if it actually created the file 
	if equal(writefile,-1) then  
	  puts(1,"opening failed: \n") 
	  puts(1,"writefilename= "&writefilename&"\n") 
	  trace(1) 

This is the printout, copied out of the dosbox the app puts'd it to:

Running. 
opening failed: 
writefilename= D:\ngrams\dbpedia\prop3\A\Autism.txt 
This is the debugger print (using ? writefilename) of writefilename:
writefilename={68D,58:,92\,110n,103g,114r,97a,109m,115s,92\,100d,98b,112p, 
101e,100d,105i,97a,92\,112p,114r,111o,112p,513,92\,65A,92\,65A,117u,116t, 
105i,115s,109m,46.,116t,120x,116t} 
 
* Press Enter to resume trace 
Like i said, the filename, copy/pasted from the Eu printout to dos commands, and to TextPad's file open, work fine.

useless

new topic     » goto parent     » topic index » view message » categorize

7. Re: file access again

jimcbrown said...

stuff


I'm going to go out on a limb and suggest that if every other app in the world can open and edit this file, but Eu cannot, then Eu has the problem, at least until Eu can explain itself in a meaningful way, not merely -1.

useless

new topic     » goto parent     » topic index » view message » categorize

8. Re: file access again

This doesn't help

trace(1)                 
        junk = dir("\""&writefilename&"\"") 

junk is still -1. Eu cannot even see the file prior to the open attempt. Filesys.e and machine.e both get the filename intact, but naturally i cannot follow the filename into the builtin routines which machine.e calls.

useless

new topic     » goto parent     » topic index » view message » categorize

9. Re: file access again


PS: There's over 143,000 files in that directory. Is there an integer type overflow going on in the Eu internals pertaining to file access?

The file itself is small:

<Diseasesdb> 1142 
<Icd9> 299.00 
<Omim> 209850 
<Medlineplus> 001526 
<EmedicineSubject> med 
<EmedicineTopic> 3202 
<MeshId> D001321 
<Name> Autism 

useless

new topic     » goto parent     » topic index » view message » categorize

10. Re: file access again

eukat said...
jimcbrown said...

stuff

I'm going to go out on a limb and suggest that if every other app in the world can open and edit this file, but Eu cannot, then Eu has the problem, at least until Eu can explain itself in a meaningful way, not merely -1.

Like I said, all it does is wrap fopen(). So someone would have to go check the next culprit, MinGW. (Or maybe the one after that, CRTDLL.)

There are some Euphoria-specific errors that can occur with open(), but these result in an ex.err-style crash with a very clear and human readable error message, not this C language "You had an error" nonsense.

new topic     » goto parent     » topic index » view message » categorize

11. Re: file access again

eukat said...

PS: There's over 143,000 files in that directory. Is there an integer type overflow going on in the Eu internals pertaining to file access?

No. On Windoze, the implementation of dir() is written by Derek and (looking at the code in trunk/source/be_machine.c, Dir() 1 out of 2) it seems that he was very careful to avoid this. The implementation calls FindFirstFile() and FindNextFile() (both from the W32/64API), reusing the same variable and replacing the old HANDLE with the new one (instead of getting a list of all the files at once and trying to do a loop through them with an integer counter).

There is a loop, but it simply checks to see if the HANDLE variable still points to a valid handle or not.

The only time that -1 is returned is when INVALID_HANDLE is returned by the FindFirstFile() W32/64API function.

new topic     » goto parent     » topic index » view message » categorize

12. Re: file access again


Perhaps it's a shell problem. If i use system() to get a dir of writefilename, it also fails:

Running. 
The system cannot find the path specified. 
But if i open a cmd.exe myself, dir worked fine.

useless

new topic     » goto parent     » topic index » view message » categorize

13. Re: file access again

eukat said...

Perhaps it's a shell problem. If i use system() to get a dir of writefilename, it also fails:

Running. 
The system cannot find the path specified. 
But if i open a cmd.exe myself, dir worked fine.

Hmm. This is a long shot, but .... one possibility that occurred to me is that maybe somehow eui and euiw both got set with Program Compatibility to an older version of Windoze ... FAT32 can only deal with less than 66,000 files in a directory, and some really early versions of Windoze could only deal with FAT32 and its predecessors. So if Program Compatibility is set back far enough, it might hide the rest of the files from eui/euiw and whatever they invoke (such as command.com for the system() call).

new topic     » goto parent     » topic index » view message » categorize

14. Re: file access again

useless_ said...


Perhaps it's a shell problem. If i use system() to get a dir of writefilename, it also fails:

Running. 
The system cannot find the path specified. 
But if i open a cmd.exe myself, dir worked fine.

useless

Hallo

As i remeber situations where Windows just don't like my filenames. I often use this as a solution.

Maybe you can try to get the Short Name of your file and pass this name to open.

Quick'n Dirty code follows ;)

include std/dll.e 
include std/machine.e 
 
constant MAX_PATH    = 260 
constant kernel32 = open_dll ("kernel32.dll") 
constant myGetShortPathName=define_c_func(kernel32,"GetShortPathNameA",{C_POINTER,C_POINTER,C_UINT},C_INT) 
 
function ShortFileName(sequence filename) 
atom inszpointer,outszpointer 
object result 
    outszpointer=allocate(MAX_PATH+1) 
    inszpointer=allocate_string(filename) 
    c_func(myGetShortPathName,{inszpointer,outszpointer,MAX_PATH+1}) 
    result = peek_string(outszpointer) 
    free(outszpointer) 
    free(inszpointer) 
    return result 
end function 
 
 
-- Just for testing... 
puts(1,getenv("HOMEPATH")&"\n") 
puts(1,ShortFileName(getenv("HOMEPATH"))&"\n") 
 

Andreas

new topic     » goto parent     » topic index » view message » categorize

15. Re: file access again

KAT said...

My app does

writefile = open(writefilename,"ab") -- and open a new file 

and i get a -1. The problem is that's wrong.

What happens when you open it as "rb" instead of "ab"?

new topic     » goto parent     » topic index » view message » categorize

16. Re: file access again


I see the problem, but cannot explain it, i have no records of the following changes.........

All last week i was running an app that originated these files, it did the create_dir() and initial open(writefilename,"ab") that created all these files. I even "documented" that code to a pastey dated 3 days ago. To use a different data source, i saved that same file under a slightly different name, and edited the source filename and the text munging section. All the code to save the munged text, i did not change. Yet the path was changed, and i cannot explain it, neither can i explain how copy/pasting the entire path\filename between the Eu dosbox print and other apps, did not fail when it should have, because the paths ARE different:

D:\ngrams\dbpedia\props3\A\Autism.txt 
D:\ngrams\dbpedia\prop3\A\Autism.txt 

What's more perplexing is i used an Eu app to copy all the files to a backup directory last night, and that file read from

object readdir = "D:\\ngrams\\dbpedia\\props3\\" 

I don't know what happened. I do not know how this app, reusing the same code as previously, became using \prop3\ instead of \props3\. I loaded and reused the same code precisely to avoid issues like this. I appologise.

useless

new topic     » goto parent     » topic index » view message » categorize

17. Re: file access again

KAT said...

I appologise.

No harm done then. It's been a useful exercise in group debugging.

new topic     » goto parent     » topic index » view message » categorize

18. Re: file access again

DerekParnell said...
KAT said...

I appologise.

No harm done then. It's been a useful exercise in group debugging.


Thanks, you are kinder about it than i am to myself, i keep looking at that hammer.....

I am too error prone and lazy to have typed out that filename so many time, i copy/pasted it from the Eu printout to Textpad, to other dosboxes. That should have failed because of the 's' in the path. Do you have any musings on that?

useless

new topic     » goto parent     » topic index » view message » categorize

19. Re: file access again

eukat said...
DerekParnell said...
KAT said...

I appologise.

No harm done then. It's been a useful exercise in group debugging.

Thanks, you are kinder about it than i am to myself, i keep looking at that hammer.....

Hammer-to-keyboard-or-monitor is a perfectly normal reaction to an event like this, at least imvho.

eukat said...

I am too error prone and lazy to have typed out that filename so many time, i copy/pasted it from the Eu printout to Textpad, to other dosboxes. That should have failed because of the 's' in the path. Do you have any musings on that?

Perhaps there was a misbehaving spellchecker extension loaded in Textpad at the time?

new topic     » goto parent     » topic index » view message » categorize

20. Re: file access again

jimcbrown said...
eukat said...


My app does

writefile = open(writefilename,"ab") -- and open a new file 

and i get a -1. The problem is that's wrong.

I can :

  • open dosbox, type D:\ngrams\dbpedia\props3\A\Autism.txt -- prints to screen
  • open dosbox, dir D:\ngrams\dbpedia\props3\A\Autism.txt -- prints data about
  • open dosbox, edit D:\ngrams\dbpedia\props3\A\Autism.txt -- opens dos editor
  • open Textpad, open and edit and save file -- performs properly

All jokes about autism and Aspergers aside, what is the malfunction here? When Eu returns -1 as writefile, there is no data to understand whatever it's problem is.

Pardon, but if I may be helpful...

said...

there is no data to understand whatever its problem is.

(Normally, I don't care since these two sound the same, but since eukat has been so helpful in pointing out these issues in the past, I thought I'd return the favor at least just this once.)

In general, it's hard to say. If open() returns -1, that just means that fopen() returned NULL instead of a valid file handle.

On a nix system, you can check libc's errno value at this point to get more useful information (e.g. was it a permissions issue, low level i/o error reported from the driver, etc.) but I don't know if the relevant analogue applies on other platforms.

At first glance, this looks like it's happening on the same disk that had the strange errors and suspected disk corruption as referenced in http://openeuphoria.org/ticket/825.wc and http://openeuphoria.org/forum/m/119991.wc

Concerning windows there is 2 calls to get information about the last error. GetLastError() and FormatMessage() both are in kernel32.dll for an exemple refer to: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680582(v=vs.85).aspx

Jacques

new topic     » goto parent     » topic index » view message » categorize

21. Re: file access again

... 
writedir="D:\\ngrams\\dbpedia\\prop3\\" & linetitle[1] 
writefilename = writedir & "\\" & linetitle & ".txt" 
if atom(dir(writedir)) then 
   if not create_directory(writedir,,1) then 
      crash("Filesystem error - could not create the folder") 
   end if 
end if 
writefile = open(writefilename,"ab") -- and open a new file  
... 
new topic     » goto parent     » topic index » view message » categorize

22. Re: file access again

cargoan said...
... 
writedir="D:\\ngrams\\dbpedia\\prop3\\" & linetitle[1] 
writefilename = writedir & "\\" & linetitle & ".txt" 
if atom(dir(writedir)) then 
   if not create_directory(writedir,,1) then 
      crash("Filesystem error - could not create the folder") 
   end if 
end if 
writefile = open(writefilename,"ab") -- and open a new file  
... 


Except the goal was to append to the existing files, to merge data. The files and folders were already created by another Eu program, using the same code, and it ran fine. Writing new data to some other folders isn't appending them to the existing files.

useless

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu