EFFS failsafe not working with FTP session open?

Discussion to talk about software related topics only.
Post Reply
khoney
Posts: 125
Joined: Fri Sep 11, 2009 12:43 pm

EFFS failsafe not working with FTP session open?

Post by khoney »

I have a process where I delete, then rewrite a file (using fs_open, fs_write, and fs_close) containing some info posted by a web client to my SD card. When I reboot the Netburner and read the file, I am sometimes getting the previous contents of the file back. I am not getting any errors in either the file delete or write. I am updating the file from a custom Post handler in my web server.

What I have recently observed is that if I have an FTP session open with the Netburner (i.e. I have the main SD card folder visible in an IE window for dragging and dropping my index.htm file), this occasional problem occurs. However, if I close the IE windows, the file operation seems to work every time. I have not proven this beyond a shadow of a doubt, just have tried the operation many more times than would have typically caused a failure.

Has anyone else ever observed this, and is there anything I can do about it? I don't expect the client to have an FTP session active under normal operation (i.e. while they are accessing the web site), but I suppose it is always possible. I don't really understand why there would be any issue with having the FTP site open while writing to the card from the HTTP task. FYI, the folder that is being viewed in the FTP window is the same as the destination folder for the file I am writing.

Any thoughts about what might be happening would be appreciated.
khoney
Posts: 125
Joined: Fri Sep 11, 2009 12:43 pm

Re: EFFS failsafe not working with FTP session open?

Post by khoney »

Hmm... so much for the FTP observation. It is not working reliably even without the FTP connection. I even tried doing a f_flush before the f_write just in case, and it makes no difference. I used the filesystemutils.cpp from the Netburner examples, and the iprintfs to the MTTY serial terminal are not reporting any errors on either the DeleteFile or the WriteFile. I also am dumping the buffer I'm sending to the WriteFile routine, and it contains exactly the file contents that I expect. I even added a readback after writing the file, and the read contents match what I wrote. However, after I power cycle and read the file I wrote, it sometimes contains the previous contents, as though the EFFS failsafe reverted to the previous file. I'm at a loss...
khoney
Posts: 125
Joined: Fri Sep 11, 2009 12:43 pm

Re: EFFS failsafe not working with FTP session open?

Post by khoney »

OK - I feel like a dufus (but not completely) :oops:

I was missing a ch_dir(\\); command. Since adding it, I haven't had any problems. Of course, this begs the question "Why was I able to delete a file and write its replacement with no errors if the current directory was not set properly?". And, of course, "Why did it work sometimes?".

We'll see if this is the permanent fix.
khoney
Posts: 125
Joined: Fri Sep 11, 2009 12:43 pm

Re: EFFS failsafe not working with FTP session open?

Post by khoney »

Guess it's not... this is really getting annoying. Is there anything else that needs to be done after a f_close to guarantee that the SD card is properly updated (FAT, etc) before powering down? I honestly don't get how I can successfully delete and rewrite a file, then reopen it and read its contents back into a buffer (that has been cleared out to ensure I'm really getting new contents), and verify that the proper data is stored in the file, but when I power cycle, the file contains the old data. I'm open to any wild theories...
BillC
Posts: 72
Joined: Tue Oct 13, 2009 6:22 am
Location: Buckinghamshire, UK

Re: EFFS failsafe not working with FTP session open?

Post by BillC »

Hi Khoney, it looks like you are having fun :cry: . I dont know if this will help but the two places in my program that have caused me similar problems (still unresolved) have been in the custom post handler, all file accesses in the main body of the program have worked fine, maybe there is some setup or protection that is needed before writing files in the post handler.

How about a test, write the file in the post handler and set a flag that the main process can read and if set read the file and see if contains your new data.

Good luck with the problem, I will watch with interest.

Cheers, Bill
rnixon
Posts: 833
Joined: Thu Apr 24, 2008 3:59 pm

Re: EFFS failsafe not working with FTP session open?

Post by rnixon »

Maybe the problem is not the file system, but rather you code is overwriting a buffer, stack, bad pointer, etc.
Try writing a small app that does not thing but write files and see if the problem is repeatable.
User avatar
lgitlitz
Posts: 331
Joined: Wed Apr 23, 2008 11:43 am
Location: San Diego, CA
Contact:

Re: EFFS failsafe not working with FTP session open?

Post by lgitlitz »

First thing you should do is use another FTP client. My preferred is FileZilla, its free, open-source, and has tons of options and debugging features. I also use the fireFTP plug-in for Firefox. I have found many issues with the windows explorer GUI FTP client. One of the worst of their features/bugs is local caching of files. I have seen windows FTP client use cached files both when I am sending or receiving. I have also found the caching issue occurs even if the file size and date changes on the NetBurner server, just the file name is the same. Lots of headaches trying to figure out what is wrong with the NetBurner until I ran a packet sniffer and saw the PC wasn't even doing anything over the network. If you close all instances of explorer and IE windows then re-open the ftp the cache will be cleared. Not a very good option if you need to reread the same file over and over. There are many other technical issues with the explorer FTP client. These issues also differ between the XP or Vista/7 versions of Windows. At initial release I could not even send files with Windows 7 FTP client but it seems that they cleared up that bug. Go to the Microsoft support or their developer support forums and you will see many unresolved threads.
Post Reply