cocoa + skip os generated files - cocoa

my app actually goes to different folders and takes each file into account and reads each file and does a lot of processing on them and marks the folder it has processed as done. but this is not happening as the system is immediately generating files like .DS_store and .localized and .trash. so is there any mechanism to skip processing hidden files or stop the os from generating these files programatically?
Thanks

Couldn't you change your app to just ignore files that start with "."? You've tagged this Cocoa, so using something like NSFileManager's contentsOfDirectoryAtURL:includingPropertiesForKeys:options:error: seems appropriate. One of the options you can specify is NSDirectoryEnumerationSkipsHiddenFiles, which will skip hidden files.
Check the documentation for more details.

I'm not aware of any option that disables the generation of .DS_Store files locally. There is an option for remote, here.
Another way to do it could be to create a unix user for just that job and let him own the dirs, so that the Finder never can go there. Either start the job manually using sudo, or make it a setuid job.. or use launchd.

Related

Octave- How to automatically execute commands on startup

I'm new to octave, and want to run a few commands on startup automatically every time it opens.
I typed "help startup" and saw "Octave uses the file ".octaverc". I did a bit of searching online at https://www.math.utah.edu/docs/info/octave_4.html, and saw the .octaverc file should be in the following path:
OCTAVE_HOME/lib/octave/VERSION/startup/octaverc
PROBLEM:
In that directory I don't have a startup folder, only "oct" and "site". I do see hidden files, which was my first thought since the file begins with "." character. So I then used Agent Ransack in the directory, and still nothing came up.
QUESTION:
1) Do I have to make the startup folder and octaverc file myself?
2) If so, does one, both or none have to be hidden?
3) Can it be a txt file, or does it have a special extension?
4) Do I just type the commands straight into the file or is there special formatting?
NOTE:
In case I'm going about this the wrong way, there are the operations I'd like to have run on startup:
PS1('>> '), addpath('D:\Users\Me\Desktop'), clc
Thanks ahead of time for the help!!
Possible locations (and their differences) for octaverc files are specified in the documentation.
In short, these are, from more general to specific:
octave-home/share/octave/site/m/startup/octaverc (most generic, for entire system)
octave-home/share/octave/version/m/startup/octaverc (to cover for more than one octave versions installed on the system, possibly requiring different startup scripts)
~/.octaverc (where ~ is unix-speak for a user's home directory -- covering for user-specific startup files)
.octaverc files in any directory, creating specific startup conditions for specific directories
octaverc files are effectively simple script files that are executed from most generic to most specific each time octave starts. Therefore, in the presence of conflicting commands, the more specific file can effectively be used to override the more generic behaviour.
Octave also supports (but does not recommend) the use of the startup.m file, for matlab compatibility.
You might also want to check out pathdef and savepath as well.
As a more general tip, if you ever want to search for a specific keyword from the documentation (e.g. octaverc), you can type this kind of search query in duckduckgo (or google):
octaverc site:https://octave.org/doc/interpreter/
(or just download the documentation as pdf and search the pdf)
Found the solution, the file was in the following path:
OCTAVE_HOME/share/octave/site/m/startup
to find out where OCTAVE_HOME is for you, just type "OCTAVE_HOME" into your Octave command line window.
ANSWERS:
1) You do not have to make a startup octaverc file yourself
2) The file is actually not hidden, so it should be easy to find given you're looking in the right place.
3) The file doesn't have an extension. It's just octaverc.
4) Under the last line of the existing file, you can just append commands as you would type them at the Octave command line window.
the last(7.3.0) octave version placed HERE:/ does not find the THERE:/openEMS/matlab directory even it is already loaded with octaverc or addpath. It keeps looking into the work dir where openEMS is not placed and does not recognize, for instance, the 'physical_constants.m' file.

Is there a way to append/remove a resource to a binary at execution time?

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.

File watcher in shell

I am trying to keep two directories synchronized with the same files in them.
Files are dropped into Directory A throughout the day. I would like to create a file watcher script that will copy files from Directory A to Directory B as soon as they are dropped.
My thought was to run the job every minute and simply copy everything that dropped in the last minute, but I am wondering if there is a better solution out there.
I'm running MKS toolkit under Windows. Different servers, same operating system.
Thanks for your help!
If you use Linux, you can hook into the kernel using the inotify API to get notified if something in a folder changes. There are command line versions like inotifywatch(1) as well.
To copy the files, I suggest to use rsync(1): it is clever, knows how to clean up after itself and it will create new files hidden while they are copied so users and programs are less likely to pick them up before they are complete.

Hiding Files in Windows

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.

Get a look at the temporary files a process creates

I'm trying to reverse-engineer a program that does some basic parsing: text in, text out. I've got an executable "reference implementation" and the source code to what must be a different version, since the compiled source output != executable output.
The process creates and deletes temporary files very quickly in a multi-step parsing process. If I could take a look at the individual temporary files, I could get some great diagnostic data to narrow down where my source differs from the binary.
Is there any way to do any of the following?
Freeze a directory so that file creation will work but file deletion will fail silently?
Run a program in "slow motion" so that I can look at the files that it creates?
Log everything that a program does, including any data written out to files?
Running a tool like NTFS Undelete should give you the chance to recover the temporary files it's creating then deleting. Combine this with ProcMon from Sysinternals to get the right filenames.
You didn't mention what OS you're doing this on, but assuming you're using Windows...
You might be able to make use of SysInternals tools like Process Explorer and Process Monitor to get a better idea of the files being accessed. As far as I know, there's no "write-only" option on folders. For "slowing down" the files, you'd just need to use a slower computer. For logging, the SysInternals tools will help out quite a bit. Once you have a file name(s) that are being created, you could try preventing their deletion by opening the files in a stream from another process. That would prevent the system from being able to delete them.
There are two ways to attack this:
Run various small test cases through both systems and notice the differences. Since the test cases are small, you should be able to figure out why your code works differently than the executable.
Disassemble the executable and remove all the "delete temp file" instructions. Depending on how this works, this could be a very complex task (say when there is no central place where it happens).

Resources