So, there isn't anything big that I'm really going to use this for, but I've have made a little batch (.bat) program that I thought would be awesome if I had this feature in it.
I don't want anything that is going to mess up my LAN network, so try to make it as simple
as possible.
So my idea is that I want it so when the program starts it scans for an update (which will be found on Dropbox), then ask the user if they want to update, then it will install an update file and delete the old one. If anyone knows a way to do this safely, please tell me, thanks!
I have a tiny bit of an idea on how this is possible, but it is not very efficient. Thanks!
I assume you have a file on your computer and one on Dropbox and sometimes you want to edit it from another computer and then when you get back home and start up the program it will check whether the Dropbox file is more up to date than the one you have on your computer?
I think the easiest way would be to either use a special file name, like, myBatchFile_update.bat or something and then make your program check for that file in your Dropbox folder. If it's there, copy it and then rename it to myBatchFile.bat or something. Also rename update file. You may want to look up copy and xcopy and ren, first.
Another way would be to keep the "if updated" information inside of the file in a function (although it's hardly functions in batch). Or you could just keep another file called for example is_updated.bat where you keep information about whether it's updated or not. You echo something like set update=true (if it's updated) to the update file when it has updated and when you have edited the program you also edit the update file so that it says false. Then, when you need the information, you just call the update file.
Related
Although we don't need it much but still if we want to know the original file, how would we do that?
How can we find the original file in case we create several hard links to a file?
I assume that you are talking about hard links in a POSIX file system.
You can't. As far as the file system is concerned, the hard links are indistinguishable.
OK. Maybe if you created the hard links via a shell, the commands might be in the shell history. Or the information might be in log files. Or possibly audit files ... if auditing is enabled. But not normally.
For a bit of background, I've got a directory on a server that is constantly having files delivered to it over time. The directory has become really big and I'm moving files out of the directory. I'm curious and not sure the best way to search for the answer so thought I'd ask here.
When I do a simple move command in a windows command shell, move * ..\Backlog\, for example, what happens? Specifically I mean, does Windows create something like an array of files at the moment you hit enter and just move those files? Or does it recreate the array of files every time a file is moved? I'm honestly just looking to learn how this works behind the scenes. If files are coming into the directory at a steady rate, are those going to get picked up by the move command even if they come in after you've executed it but while it's still running? Hopefully my question makes sense, thanks.
When you call "move" files are not actually moved on a disk, only the directory listing (which is effectively a file with some addresses associated with filenames) is changed.
I'm pretty sure that when you call move * dest, the * gets resolved at once and all of the files at that very specific moment in time are moved. Anything that goes into that directory during the process is not included in the move.
when writing a file using NSFileCoordinator i need to specify the correct NSFileCoordinatorWritingOptions. Although they are explained in detail, I am not sure when to use which one. The available options are:
NSFileCoordinatorWritingForDeleting
NSFileCoordinatorWritingForReplacing
NSFileCoordinatorWritingForMoving
NSFileCoordinatorWritingForMerging
For example, what option is the correct one if I want to create a file (a plist for example)?
Wich one when I modify a file?
Can someone explain the NSFileCoordinatorWritingOptions for a better understanding?
I agree, documentation is not complete on that front, and hard to understand. And no sample code is available even for basic operations like these.
I try to think of these options in the perspective of other apps that have that specific file open, that helps getting the whole picture.
Pass no option (0) to simply update the file and notify others of your changes.
Let's say you are deleting a file that TextEdit currently displays, by providing the NSFileCoordinatorWritingForDeleting option, you're telling TextEdit to close the file as it does not exist anymore (or it could propose to save it to another place if it's in memory). It acts because of deletion.
If you're overwriting a file (as opposed to updating a file), you want about that same behavior for other apps. That's NSFileCoordinatorWritingForReplacing.
NSFileCoordinatorWritingForMoving says other apps to track the file to it's new location, so that it can be later updated.
NSFileCoordinatorWritingForMerging asks other processes to first commit their changes so that you can then merge your own changes with those.
To answer your question, you should use NSFileCoordinatorWritingForReplacing when creating a new file (even when no file exists, as it was to appear in the mean time from another app, you'd be replacing it with your own, unrelated contents). And NSFileCoordinatorWritingForMerging should be used when updating an existing file with new data, as it allows integrating the latest changes to that file immediately (instead of doing later with conflict resolution).
Currently, I'm developing a system which will extract some files from an SFX archive (files that will be used for another app). I want to make the extracted files hidden, so the person which has find the location of the exe couldn't get the files which will be in same directory with the exe. I know i can apply attrib +h to the files but if the user turns on "show hidden and system files" option in Windows, the files will be visible.
Isn't there any method to overcome this? Any suggestion is welcomed.
Thanks.
If you're writing to the disk, a user can find and read your file. There's no way around that, one could monitor what happens when your application is run, find what files it's writing to, or just intercept while it's being written. Consider why you don't want the user to find your files.
Is it because there's sensitive data, or things you'd rather they didn't change? Consider encrypting it, or verifying it's integrity with a checksum or hash.
Guess you could play around with user rights. However, you'd need to ask an administrator right at install then to make it hidden from the given user who is an admin on the PC.
I would like to upload documents to GoogleDocs every time the OS hears that a file was added/dragged/saved in a designated folder, just the way DropBox uploads a file when you save it in the DropBox folder.
What would this take in Ruby, what are the parts?
How do you listen for when a File is Saved?
How do you listen for when a File is added to a Folder?
I understand how to use the GoogleDocs API and upload things once I get these events, but I'm not sure how this would work.
Update
While I still don't know how to check if a file is added to a directory, listening for when a file is saved is now dirt simple, thanks to Guard for ruby.
If I were faced with this, I would use something like git or bzr to handle the version checking and just call add then commit from your script and monitor which files have changed (and therefore need to be uploaded).
This adds the benefit of full version control over files and it's mostly cross platform (if you include binaries for each platform).
Note this doesn't handle your listening problem, just what you do when you know something has changed. You could schedule the task (via various routes) but I still like the idea of a proper VCS under the hood.
I just found this: http://www.codeforpeople.com/lib/ruby/dirwatch/
You'd need to read over it as I can't vouch for its efficiency or reliability. It appears to use SQLite, so it might be better just to manually check once every 10 seconds (or something along those lines).
Ruby doesn't include a built-in way to "listen" for updates to files. If you want to stick to pure Ruby, your best bet would be to perform the upload on a fixed schedule (say every 5 minutes) regardless of when the file is saved.
If this isn't an acceptable alternative, you could try writing the app (or at least certain parts of it) in Java, which does support this type of thing. Take a look at JRuby for integrating the Ruby and Java portions of your app.
Here is a pure ruby gem:
http://github.com/TwP/directory_watcher
I don't know the correct way of doing this, but a simple hack would be to have a script running in the background which checks the contents of a bunch of folders every n minutes and uses the associated timestamps to determine if the file was modified in that span of time
You would definitely need some native OS code here, to write the monitoring service/client. I'd select C++ if you want it to be cross platform. If you decide to go with .Net, for example, you can use the FileSystemWatcher class to achieve what you need (documentation and here's a related article).
Kind of an old thread, but I am faced with doing something similar and wanted to throw in my thoughts. The route I'm going is to have a ruby script that watches a given directory and checks the timestamps. Once all files have been uploaded, the script saves the latest timestamp and then polls the directory again, checking if any files/folders have been added. If files are found, then the script uploads them and updates the global timestamp, etc...
The downside is that setting up a ruby script to run continually (or as a service) is somewhat painful. But it's not an overwhelming task, just needs to be thought out properly.
Also depends on if your users are competent enough to have ruby installed or if you have to package everything up into a one-click installer as well. That, to me, is the hardest part to figure out.