I have an application that performs some processing on files dropped into a 'watch folder'. The problem I'm having is detecting when the file copy to the folder is complete.
The application needs to run on both Windows and OSX, so ideally I'd like a cross-platform solution, although there is no reason (other than future maintainability) for using the same algorithm on both platforms.
The way I'm doing this at the moment is to wait until I can get a read lock on the file (by just trying to open it), then periodically checking the size of the file to make sure it's not getting any bigger.
Once both of those criteria have been met, I process the file.
The problem I'm seeing is that once in a blue moon, the two criteria will be met when the file is still being copied. My gut feeling is that it's caused by momentary network congestion, but I've been unable to reproduce the issue whilst debugging.
I can probably make it more stable by just throwing a few more checks at the problem and tweaking the time-out values, but the software engineer in me would like a more definitive solution.
One solution I've used is to write the new file to one directory (on the same system) and, when done, moving it to the target directory (on the same system) using the Win32 API, which is an atomic operation.
For one variation, we wrote the file to the same directory, but with an extra extension like ".~tmp" and then did the rename/move operation.
Exactly. That is how browser file downloads work and most other file copy programs that I know of work. The destination filename does not appear until the file is complete.
I'd change your file copy program to copy to a temp file with 'guid-like' name or at least a .~nonsense extension and rename it after the transfer is complete. There are ways to do this, keeping such things as the file timestamp intact.
Today when i was reviewing a part of C++ i noticed continue in some cycles (to be exact i managed to see atleast one example of each cycle with continue)
I remember beeing told that go to and continue shouldn't be used. You can easily do whatever you need with some other tool in c++ semantics.
What do you think? Is using continue a good practice?
I have no doubt a good programmer can write good programs with any syntax element of any language, but that doesn't mean that everyone should! Even the best program deterioates over time. Of all elements of the C/C++ language, goto is the one with the biggest potential for abuse, and the biggest potential for misinterpreting its intended use when maintaining the code. Therefore, even if you're the worlds best programmer, you should never deliberately use goto without a very good reason, and only if the existing alternatives would present a bigger potential for maintenance problems in the future.
You might argue that for throwaway code that you know is going to be ditched within a couple of months there is really no risk, but some of the most long-lived tools were originally designed as throwaway code. Even if the program as a whole gets thrown away, parts of it may be reused elsewhere. We are in an age of VCSs and code reuse; you can't take back code: once you've written it it can not be unwritten!
I am against ternary operator because my ancient VC++ stopped cooperating when I want to watch the variable in debug mode. It just won't paste it correctly.
I know this is not a good reason and I need to upgrade to whatever MS is pushing today.(LOL)
But if you use continue or ternary operator it NEEDS to be commented so one can remain sane when in debug mode!
I sometime use goto and label to have a common point for generic error code, but I would be curious if optimizer would do the same in release code anyway.
Actually a lot of programmers cant handle casting and pointrs. I wrote some C code that couldnt be maintained by another team, so they took my product, f***ed it up, made it slower and then released it to the customer.
Oh, they also couldmt understand why doing heavy work in the GUI thread was a bad idea. Dumbfucks. I had it in a seperate thread, but they didnt know why, and probably never did even after I pointed out to them that their app didnt paint or respond to button clicks.
Today when i was reviewing a part of C++ i noticed continue in some cycles...
Use of 'continue' within a loop to request branch back to the next loop iteration is the main reason for its existence and accepted practice.
Use of 'continue' with a label as a subject of a 'goto' is probably some code that was translated from FORTRAN where 'continue' also exists but means something quite different. This combination of 'goto' and 'continue' should not be used anywhere in C or C++ and should be exterminated wherever found.
In C/C++, use of 'goto' (without continue) is disparaged and at best, controversial. It can be justified in some languages but I never use it in C/C++ and would question such code and require justification for every instance, in every code review.
[I came from an age where 'goto' was prolific.]
Last Visit: 31-Dec-99 18:00 Last Update: 23-Sep-23 20:34