Im making a command line tool for Mac that does some work on .strings files. Part of the process is making a backup of the .strings files it will operate on so that, in case something gets messed up, the user's files will still be safe somewhere for retrieval.
What directory is in your opinion best to save such data? I'm assuming a temp directory of sorts but not sure where that should be. If this was an application in the macOS sense, i could store this data in the application folder. However this is a command line tool which will be added in /usr/local/bin, following the UNIX way of doing things, and it would feel "wrong" to put that data in there.
Related
So the images below were originally a vb files. I have just opened it and it looks like this and the compiler won't run it. I am unsure whether this is a compiler error or whether it may have become corrupt because the project is stored on an external drive. It is just these two forms that have broken like this; I have one other form and a module in the same project that are okay but the project can't run because of the two that are broke.
Broken Login Form
Broken Diary Form
If it changes anything, the designer files for the forms are intact it is just the scripting for the forms elements that is broken.
Also, if I can't identify the cause, is there a way to revert it back to the last working version in visual studio to get my code back? Just because I put a lot of time into it.
The data in those files is most likely gone.
IMPORTANT: Do not write anything to that disk drive unless you find that you cannot recover those files.
If you are using a version control system then you can revert to an earlier version.
If you are using Windows 10 and you happen to have stored those files in a location included in what File History saves, you can recover them from that.
If you use some other form of backup, retrieve the files from that.
If you have a separate disk drive with at least as much free space as the one with the corrupted files, you could try running file recovery software as it might be that the zeroed-out file was written to a different place on the HDD.
TinTnMn pointed out in a comment that if you previously compiled the code, you should have executable files in the "obj" and "bin" folders that can be decompiled to recover most of your work
It could be quicker to re-write the code while it is still fresh in your mind.
Is it possible to append/remove a ressource file to a binary at execution time?
I have an application written with go, which saves/searches data from a database file, and i would like this database file to be embedded to the binary, and updated by the application itself.
This way the application would be self contained with its database.
Modifying the executable, this is generally a very bad idea.
Several issues pop right into my head, such as:
Does the current user have sufficient permissions?
Is the file locked during execution?
What about multiple running instances of the application?
Even if you manage to do just that, think of what anti-virus and firewall applications will say to it: most when they detect the change will flag the executable and/or contain it, or deny running it, or some may even delete it. Rightfully, as this is what many viruses do: modify existing executables.
Also virus scanner databases maintain reports where files (their contents) are identified based on the hash of their content. Modifying the executable will naturally change the file content hash, thus render the file unknown / suspicious to these databases.
As mentioned, just write / cache data in separate file(s), preferably in user's home folder or in the application folder (next to the executable, optionally in sub-folders). Or make the cache file / folder a changeable option (command line flags).
Technically, this is possible, but this is a bad idea. Your application could be run by users not having write permissions to your binary.
If you're talking about a portable app, your best option might be using a file in the same directory the binary is located, otherwise - use the user's home directory according to the conventions of the OS you're running on. You can use the os/user package to find the home directory.
I'm new to ruby ... and shoes... and programming but here is my prob:
I made a timer which puts the timed amount into a txt file as a log. It also keeps an all time running total in a separate txt file. It works as I want it to...
I tried packaging it:
If I package the rb file it doesn't work, it will only work if I package the entire folder including the txt files.
This working copy seems to operate without txt files (they are somehow built-in. Is there a way to package this so I still have access to the associated txt files. (maybe has something to do with the paths...)
thanks.
Shoes Packager behaviour is sometimes ugly. I think you're using windows, so i'll try to explain what seems to happen:
You have a bundled Shoes-App (a standalone .exe file). Every Time you start it by double clicking, it will extract itself in a new temp dir (located under c:\tmp\tempFileDirectory). So, it is a NEW temporary Directory, everytime!
The current path also is set to this tmp directory, which also includes the txt files you bundled into the app, in it's original state. If you change the content of the files during the app execution, and restart the app, your changes are gone, because in the new created tmp dir, there is a fresh copy of the original txt files. so far, it is a BAD idea to put your data files (txt in your case, or SQLITE-database-files, or config files, ...) into the bundles app.
Better way:
create a "hidden" folder (folder's name should start with an ".") in the user's home folder. On windows it should be something like "c:\Users\YourName". Create there everything you need, this directory won't be temporal, so you can access it everytime without problems. This should general be a better solution when programming desktop stuff, not just while using shoes.
I've developed a GUI for some build scripts, and am now in the process of deploying it. As the script will be deployed to a number of different machines at various points, I need to use the standard format of directories that the team use.
The GUI consists of a ".fig" file that contains the visual definition of the UI, and a m-script that defines the functionality. I need to locate these two in "fig/" and "m/" folders respectively, but I can't figure out how to. I first searched for an include statement of some kind in the m-script, as when I Run it on its own, the error message in the command window states that the ".fig" file can't be found, but there doesn't seem to be a reference to the ".fig" file anywhere, I assume that it's inferred as both files have the same name but a different extension.
I fear that Matlab's GUI system requires that both ".m" and ".fig" files are in the same location, but this will be an inelegant solution that I'd rather not go for if I can avoid it.
The next thing I'm going to try is to call a script that copies the fig file from the other directory to the same location as the m-script, when it is executed, then deletes that copy once the script exits, which again seems a clunky solution, but will allow me to adhere to the team's organisation conventions.
Does anyone else know of an undocumented means of specifying the relative location of a GUI ".fig" file?
You can export the GUIDE-generated GUI as a single .m file. Check out this blog post: GUIDE GUIs in All One File.
I'm not sure if this is a new feature, or one of those things that has always been there...
I have a Windows service application on Vista SP1 and I've found that users are renaming its executable file (while it's running) and then rebooting, thus causing it to fail to start on next bootup because the service manager can no longer find the exe file since it's been renamed.
I seem to recall that with older versions of Windows you couldn't do this because the OS placed a lock on the file. Even with Vista SP1 I still cannot copy over the existing file when it's running - Windows reports that the file is in use - makes sense. So why should I be allowed to rename it? What happens if Windows needs to page in a new code page from the exe but the file has been renamed since it was started? I ran Process Monitor while renaming the exe file, etc, but Process Mon didn't report anything strange and just logged changing the filename like any other file.
Does anyone know what's going on here behind the scenes? It's seem counter intuitive that Windows would allow a running process' filename (or its dependent DLLs) to be changed. What am I missing here?
your concept is wrong ... the filename is not the center of the file-io universe ... the handle to the open file is. the file is not moved to a different section of disk when you rename it, it's still in the same place and the part of the disk the internal data structure for the open file is still pointing to the same place. bottom line is that your observations are correct. you can rename a running program without causing problems. you can create a new file with the same name as the running program once you've renamed it. this is actually useful behavior if you want to update software while the software is running.
As long as the file is still there, Windows can still read from it - it's the underlying file that matters, not its name.
I can happily rename running executables on my XP machine.
The OS keeps an open handle to the .exe file,. Renaming the file simply changes some filesystem metadata about the file, without invalidating open handles. So when the OS goes to page in more code, it just uses the file handle it already has open.
Replacing the file (writing over its contents) is another matter entirely, and I'm guessing the OS opens with the FILE_SHARE_WRITE flag unset, so no other processes can write to the .exe file.
Might be a stupid question but, why do users have access to rename the file if they are not suppose to rename the file? But yeah, it's allowed because, as the good answers point out, the open handle to the file isn't lost until the application exits. And there are some uses for it as well, even though I'm not convinced updating an application by renaming its file is a good practice.
You might consider having your service listen to changes to the directory that your service is installed in. If it detects a rename, then it could rename itself back to what it's supposed to be.
There are two aspects to the notion of file here:
The data on the disk - that's the actual file.
The file-name (could be several or none) which you can give that data - called directory entries.
What you are renaming is the directory entry, which still references the same data. Windows doesn't care about your doing so, as it still can access the data when it needs to. The running process is mapped to the data, not the name.