I am using IIB, and several of the requirements I have are for message flows that can do the following things:
Download a file from an FTP and/or SFTP server to the local file system, with a different name
Rename a file on the local file system
Move and rename a file on the (S)FTP server
Upload a file from the file system to the (S)FTP server, with a different name
Looking at the nodes available (FileInputNode, FileReadNode, FileOutputNode); it appears that they can read and write files in this way; but only by copying them into memory and then physically rewriting the files - rather than just using a copy/move/download-type command, which would never need to open the file in the same way.
I've noticed that there's options to move store files locally once the read is complete, however; so perhaps there's a way around it using that functionality? I don't need to open the files into memory at all - I don't care what's in the files.
Currently I am doing this using a Java Compute Node and Apache Commons Net classes for FTP - but they don't work for SFTP and the workaround seems too complex; so I was wondering if there was a pure IIB way to do it.
There is no native way to do this, but it can be done using Apache Commons VFS
Related
I Have a application on Clipper,DBF.
Is It Possible to access DBF file from FTP Server Using Clipper Program?
Thanks.
No, not really.
FTP is not a "shared folder". You can create a batch file which will download file via FTP, then run your clipper application, then after application finishes copy modified .DBF back to FTP server.
Note however that it will be slow (as you need to transfer whole .DBF file even if you need just a tiny bit of it) and that you MAY NOT use it at more than one place at a time (running it in more than one place will overwrite data, including possibility of file truncation/corruption)
There are utilities that present FTP as a filesystem ("shared folder"), for example curlftpfs, but while it allows you to just run .exe directly instead of via aforementioned .bat file, ALL THE LIMITATIONS mentioned in previous paragraph still apply - it is not possible to avoid them due to nature of FTP.
I have one application in which I download files from FTP server.
As the file is downloading, a third party begins uploading that file and so it ends up with a corrupt file and is unable to process it.
Does any know about how to deal with situation other than using .complete file mechanism? (keeping track of when the download is complete)
Is it possible to lock the file on the FTP server? The FTP server is windows.
No, there is no standard locking mechanism, it's all between up to you and the other party. Here are some ways to do it in addition to creating a .complete file;
The uploader uploads the file as file.xls.tmp, and when it's complete, rename to file.xls.
The uploader uploads to a tmp directory, and when it's complete, moves it to the scanned dir.
The uploader uploads the file, and the downloader scans file dates to find files written before a certain time. This is not as reliable, since a file from a crashed uploader may be scanned.
There are probably more versions, particularly with a custom ftp server, but using the plain standard doesn't allow for much "fancy stuff".
I have files stored in a shared directory on one computer and a Cocoa Application running on another computer on the same LAN.
I want the application to move files within the shared directory.
I’m using -NSFileManager copyItemAtPath: toPath: error:. But sometimes it seems extremely slow, regardless of file size. Why would that operation be much longer than doing it directly on the shared directory’s computer?
I'd guess, I don't know for sure, that NSFileManager first downloads the file to copy and then reuploads the downloaded file under a different name. The last thing it does is removing the original file. Of course the downloading and uploading take some time.
The reason for this procedure is that most protocols don't have a 'copy' command. So the client will have to do all the work itself with the explained procedure.
In my application, i have one exe file that will do some conversion on my videofiles in a directory, and also i have used cute ftp to transfer the files present in the directory to another server.
CUTE FTP is configured to be run on every mins.
When 25% of job is over for a video file, CUTEFTP is transferred that file to other server.
What are the ways to fix this problem.
Process the file in a different directory and then move it to a place where CUTE FTP will pick it up after the conversion is finished.
[EDIT] Don't use copy, use move. Both directories must be on the same harddisk. When using the Windows Explorer, use "Cut" or just drag the file with the mouse. Make sure there is no little "[+]" when you drop it.
I need to be able to store configuration files on machines that gets disconnected by plugging off the electricity ;), I'm using basic WinApi to store configuration data (WriteFile), this works unless the machine is plugged off ;), sometimes file isn't saved at all.
I was thinking of 2 solutions:
1) Transactional NTFS API (eg. CreateFileTransacted() ), but this thing works only on Vista and NTFS has to be present and I can't use it in most cases
2) To create a backup copy of configuration file in %APPDATA% directory, say 20 backup copies and restore them on application startup when damaged configuration file is detected
If you know of any other solution to my problem (the main problem is turning off the machine by plugging it out), please let me know. Thank you.
You don't really need 20 backup copies. You only need 1 - the last copy. Now, if your client actually asks for a basic versioning system for config files that is another story. But just to have a good config file you only need 1 backup.
Now, here's what I used to do for my embedded projects:
Calculate a hash of the config file and store it in the file. The easiest is to append it to the end of file as a comment. I used to use crc32 for this but these days I would use SHA1. This can even be done automatically by a config-uploader tool just prior to transmitting/storing the config file.
When opening the config file, extract the hash and compare it with the value calculated from the file (obviously calculated after the hash is removed from the file). If the hash is not there then the file is incomplete. If the hash is not the same then the file is corrupted. In either case use the older file.
Now that a valid & correct config file is verified it can replace the older config file. Use the OS's rename operation for this. It is usually atomic on most modern filesystems so a failed rename will not clobber up the old file.
This is the most robust system I've used in my years of experience. It's basically what bittorrent does.