I've got the following problem: For my Free Pascal project I set up FileAssociation (https://github.com/lainz/FileAssociation / https://wiki.freepascal.org/FileAssociation) with my program's icon as the icon for the file type that is supposed to be opened in my program. And it does work - the file association is done at every start of the program (in the FormCreate procedure) and the respective files get the intended icon. But every time I actually open a file with my program its icon disappears and only reappears when the program is closed and restarted.
My file type is .planez which isn't used by any other program (at least on my computer).
How can I set a persistent file type icon which never disappears?
Related
I recently noticed this icon being shown on my workspace, where it used to not have the tildes. What does this mean?
The waves are the symbol for a stream. I think having them overlaid on a workspace means the workspace is associated with a stream (rather than being a "classic" workspace with a manually specified depot mapping).
Most file systems use locking to handle concurrent read/write. But what if after a read call, a write call is executed which deletes the data preceding the previous read call.
Is the pointer for a file open for reading updated to reflect the new start of the now smaller file?
The question isn't really valid, because you can't delete data using the write system call. You can overwrite data using the write(2) system call, but you can't delete data. Now, you can truncate the file using the truncate(2) system call. This changes the size of the file (reported via the st_size field by the stat(2) system call), and any bytes after the end of the file as reported by changed st_size will be zero. You can increase the size of the file using the truncate system call by requesting a new size which is larger than the current size. It is undefined (per the POSIX specification) whether this is allowed, or what the system will do when it recieves a truncate larger than the current size of the file. On many file systems it will simply set the size of the file to requested size.
OK, a few more concepts. Associated with each open file structure is a file offset pointer. Attempts to read or write a file using the read(2) or write(2) system call will advance the offset pointer by the number of bytes read or written. If you open a file twice using the open(2) system call, you will get two file descriptors, which each refer to a different open file structure, and in that case, a read(2) or write(2) using one file descriptor will not change the file offset for the other file descriptor. (If you clone a file descriptor using the dup(2) system call, then then you will get a second file descriptor which points to the same file structure, and then changes made to the file structure via one file descriptor, using the read(2), write(2), or lseek(2) system calls will be reflected via the cloned file descriptor. But that's a side issue, so that's all I will say on this topic for now.)
Now, if you truncate the file, this doesn't change the file offset in the file descriptor. However, any bytes after the truncated size will be zero if read. So the answer is that file offset pointer won't be updated after the truncate, but an attempt to read beyond the truncated size of the file will return all zeros.
When you press ctrl-t when dd(1) is running it tells you how much data it transfered and how long it has been running. If you press it during a cp(1) you can see which file it is up to and the percent done copying.
I'd like to add the same type of feature to my program. How can I do that?
I've written a short script (in another language, happens to be Python) which passes arguments to the command line as follows -
ildrt <path/filename.sav> -args p1 p2 --o1 --o2
where p, o are positional and optional arguments respectively (obvious). To get to the point, this script calls an IDL routine any number of times. Each time, the IDL virtual machine is loaded, the IDL routine runs until completion, rinse and repeat.
Unfortunately if an error occurs in the IDL routine execution a dialog box will popup and halt program execution until manually clicked. Since the idea is to run this as a batch process I want to ignore the dialog boxes, (accepting the error), and continue to the next run. Any thoughts on preferences or optional commands I can run IDL with to prevent the popups? Thanks in advance.
I guess I'm not following. Can't you just pass a flag to your program and then check that flag before popping up a dialog in your code? If you don't have access to the .pro code, then I don't think you can prevent the popups.
I am trying to make .txt file look like a .jpg file so it can be sent across wi-fi using an Eye-Fi SD card. The card only sends .jpg files for several reasons. One reason is that the transmission path of the picture from an the SD card to the computer looks like:
Camera writes pictures to EYE-FI SD -> EYE-FI connects to local router -> local router uploads to EYE-FI servers -> EYE-FI servers upload to your computer.
[Explanation]
There could be some filter on the server end, so I found some software that allows the user to bypass the eye-fi servers so now I know I am only dealing with the SD card. It's also nice to know that no one else is looking at my files. After some experimentation, I figured out that I can put .jpg files on the card and have them transmitted once a picture is taken. I also found how that the pictures must be named in short format; a name not longer than 8 characters(excluding file extensions), this probably has to do with the fact the card is formatted in fat32 (the card can be reformatted and still works). I tried uploading a .txt file to the card and gave it a similar format, and renamed it as a .jpg file. It did transfer which indicates to me there is probably something other than a file extension which denotes how the file is formatted.
[Questions]
1) Is there someway I can spoof .txt files to make them look like .jpg files?
2) Is there some kind of program I can use (for linux) to play around with values on the card so I can figure out what triggers an upload? Any ideas one what could trigger the upload?
1) Yes, there are hex value in the file that indicate it is a .jpg. If you open up a .jpg file with a hex editor, you will notice that there are header lines that have a bunch of information about how the image was compress, sometimes what made the image, some firmware information etc. In the editor, you can find the string "FF D8" this indicates the beginning of image file. This is followed shortly by "FF C0". The next 6 bytes contain information about the size of the image, and (I am guessing) is used by whatever software displays the image. The end of a jpg file is denoted by the 2 byes "FF D9". Fun fact, I played around with the jpg file I was using and it seems that you can put text after the "FF D9" and still have the jpg operate. I thought this was neat. Source
None of this was needed to get the eye-fi to upload the file though. As I said in my question, the card needs the name of the file to be in short format (which means the title cannot have more than 8 characters) and needs to have an acceptable file extension, in my case I used ".jpg". I wrote a text file, and just saved it as a "text.jpg". I found that there is a minimum size required in order to transfer the file, which is strange.
My hex editor of choice for this was bless, it is good for opening files, but I have yet to figure out if it can open volumes. It doesn't seem like it can.