nitulandia Posted April 18, 2009 Report Share Posted April 18, 2009 Hello all, LV ver in use: 8.2 1) I have a stand-alone app ("GETFILES.exe") that every X num of mins gets a bunch of files from a database, and copies them over to my machine -let's say to "folder Y"- 2) I'm writing an app that will look into "folder Y" every so often, and then will copy whatever files it finds to another location. There is a potential case in the scenario from above on which my app could try to copy a file that it is not fully downloaded just yet: The "GETFILES.exe" is in the middle of downloading a file, and my app happens to be looking for files at that instance. Before I copy the file over, I would like to make sure no other process is doing anything with it. Any suggestions as to how to accomplish this in LabVIEW? Based on some reading I've done, they recommend I open the file first, and the claim is that I should get an error if the file is still being transferred. I've tried doing this, however, the OpenFile VI does not return any errors, even if the file is in the middle of the transfer. Any pointers will be appreciated much. Cheers, edp Quote Link to comment
Mark Yedinak Posted April 18, 2009 Report Share Posted April 18, 2009 Are you opening the file for write access or read only? I don't think you will get an error if you open it for read only but you should if you open it for write access. Quote Link to comment
asbo Posted April 18, 2009 Report Share Posted April 18, 2009 It depends, I think, on the type of lock the other program has on it. There are normal locks and there are exclusive locks. In the latter case, you should indeed get an error when trying to open an exclusively locked file. However, I don't believe many programs use these. Try doing a read and see what happens as well. Maybe even try writing something to filesize+1 and then deleting it back out if it works. There's always mucking about in the Windows API - there's definitely a routine which will get you the information you want, as I've used several programs which enumerate the processes with a lock on a file. Of course, you could always try deleting it - if it works, you know for a fact it wasn't still being downloaded. Quote Link to comment
LAVA 1.0 Content Posted April 18, 2009 Report Share Posted April 18, 2009 Why don't you download the file with a temporary filename and then delete the original and rename the temporary file? This is how firefox handles these kind of stuff, they just add a .part to the filename. Ton Quote Link to comment
jdunham Posted April 18, 2009 Report Share Posted April 18, 2009 It's kind of lame, but you could check the file modification time, and not copy any file which is less than 5 seconds old. Of course if your network is flaky, that may not be enough time. If you wrote getfiles.exe, then I agree with Ton that you should modify that program to copy to a temporary file name and rename it when the download finishes. Quote Link to comment
nitulandia Posted April 18, 2009 Author Report Share Posted April 18, 2009 Thank you for the suggestions; I've found a couple of ways that meet my needs: 1. Wrote a CVI function (compiled it as .dll then imported it into LabVIEW). The function tries to rename the file. If the file is being used I get an error msg "access denied". I've pasted the function below, in case anyone is curious. 2. If I use the VI "move file" while the transfer is in process, an error is generated by the VI. /**************************************************************************** * CheckIfFileIsBeingUsed * Checks to see if a file is being accessed by another application * *****************************************************************************/ int CheckIfFileIsBeingUsed (char FileName[], char TempFileName[], int *AccessDenied, char ErrMsg[]) { int FileCode = 0; FileCode = RenameFile (FileName, TempFileName); switch (FileCode) { case 0: strcpy(ErrMsg, ""); RenameFile (TempFileName, FileName); //Success break; case -1: strcpy(ErrMsg, "File not found or directory in path not found"); break; case -3: strcpy(ErrMsg, "General I/O error occurred"); break; case -4: strcpy(ErrMsg, "Insufficient memory to complete the operation"); break; case -5: strcpy(ErrMsg, "Invalid path, for either of the filenames"); break; case -6: *AccessDenied = 1; strcpy(ErrMsg, "Access denied"); break; case -7: strcpy(ErrMsg, "Specified existing path is a directory, not a file"); break; case -8: strcpy(ErrMsg, "Disk is full"); break; case -9: strcpy(ErrMsg, "New file already exists"); break; default: strcpy(ErrMsg, "Error Undefined"); } DeleteFile(TempFileName); return FileCode; } Quote Link to comment
asbo Posted April 18, 2009 Report Share Posted April 18, 2009 QUOTE (nitulandia @ Apr 17 2009, 11:33 AM) The function tries to rename the file. If the file is being used I get an error msg "access denied". I've pasted the function below, in case anyone is curious. Oh, DUH. I don't know why I didn't think of this - back in text-based programming, I would always just rename a file to itself (whatever.zip -> whatever.zip). It would fail if the file was locked and if it succeeded, I had no extra cleanup to do. Quote Link to comment
nitulandia Posted April 23, 2009 Author Report Share Posted April 23, 2009 QUOTE (asbo @ Apr 17 2009, 12:24 PM) Oh, DUH. I don't know why I didn't think of this - back in text-based programming, I would always just rename a file to itself (whatever.zip -> whatever.zip). It would fail if the file was locked and if it succeeded, I had no extra cleanup to do. I've attached 2 files: one is the .dll and the other one is the VI Note: VI was created using LV 8.2 Quote Link to comment
asbo Posted April 23, 2009 Report Share Posted April 23, 2009 Are you sure you want to be dependent on a DLL? You can use the native Move node to implement exact same logic. I tried to move a file onto itself (as I mentioned before) but LabVIEW was ever so kind enough to inform me that the destination and target paths are the same. :thumbdown: Conclusion: Windows needs a /dev/null/. Quote Link to comment
jdunham Posted April 24, 2009 Report Share Posted April 24, 2009 I just started transferring a huge file with drag and drop on the Windows explorer, and LabVIEW threw error 5 when I tried to open it. I tried the same thing with LabVIEW doing the copy (using the Copy File primitive), and got the same result. So I think the original advice was good, and maybe you should fix your GETFILES.exe to be more compliant with Windows. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.