Re: Clearing file cache to read what's really on disk
- Posted by jimcbrown (admin) Feb 06, 2012
- 1671 views
I know I am asking a lot of questions, but this problem is really complicated, and a lot of detailed information is required to accurately diagnose this issue.
Sorry, did I say it only happened with NetDrive? It also happens when I am at my desk looking at the file on the internal network.
Right, because your program has written it via NetDrive, but NetDrive hasn't flushed it out from cache to FTP yet, so when you look at it directly you see the older version of the file.
No, I'm writing directly to file via the internal network; the data is being written perfectly.
How are you writing it? If it's via FTP you'd still need to use NetDrive or a similiar utility to map it to a drive, so I'm guessing that you can just map the directory as a CIFS share (windows mapped drives) when you are on the internal network. And doing so allows you to write to it without using NetDrive at all - and then check that it's been written to by using NotePad on the server where the file is stored itself (again without using NetDrive at all). That's the only thing that makes sense, so I'm going to go with that assumption.
If you are directly using NetDrive on the internal network to do either reading or writing, then NetDrive hasn't been eliminated as a suspect.
I'm reading via NetDrive so I can do it from home. I can read it fine if I turn off my laptop and power it up again - the first read reads all the data written, and that never changes till I power off & on again.
I can read it through the internal network with notepad - and same thing. The version I read the first time is the only one I read until I power off & on again.
Ok, just to be perfectly clear - you write to it either using the internal network, by mapping the drive to a share (e.g. CIFS or SMB) or directly on the server (so it's a local write) but either way without using NetDrive at all, and then you read it (on a different computer) through the internal network with notepad, and you get the old version?
I can't make the logger write directly to a file actually located on my computer - it's not at a constant IP address.
Well, for test purposes it would be nice to try to have the logger write to a normal file on C: drive, and see if you can see the updates right away.
If that doesn't work, you probably need to call flush() more often.
Beyond that, you could test the logger with a regular mapped drive.
If that doesn't work, you probably need to call flush() more often.
Beyond that, you could test the logger with a regular mapped drive.
A test that completely removes NetDrive from the equation is necessary to demonstrate that this is in fact not a NetDrive problem at all.
Well, do you have any links documenting this Windoze read cache feature?
No. I will do some more tests since it is clear that there is no simple answer to my initial query. I will write a program to just save ever-increasing text to a file like the logger does, and try the same test on the same machine. And so on. And I will let you know what the result is.
flush() flushes out a write cache; there is no equivalent to clear a read cache, I guess?
A
The tests are a good idea, they'll help narrow this issue down. Still, even if it is a Windows issue, we might not be able to help too much. At least, it sounds like it's not directly caused by an issue or problem in Euphoria itself.
A read cache is not really typical. The write cache points to a memory buffer that's used to speed up disk I/O (you can "write" data to a file and the go do toher stuff while the data is committed to disk in the background) but the with network filesystems like SMBFS, CIFS, NFS, etc there's another layer of caching (in this case it's suppose to be transparent, hence no need for the application to call to do a read cache flush).
It sounds like NetDrive's stuff is either not meant to be transparent (you're suppose to explicitly flush the FTP/webDAV cache) or if it is suppose to be transparent then it is implemented in a really poor way.