Can somebody please explain me the technical structure of an AppleScript LIST saved in a text file? There must be a length (entries counter) somewhere inside.
I had a little crash and the saved file looks like corrupt now. It always shows 1800 entries instead of 2600 before. And there are for sure more than 1800 entries. I also think it cannot be like an EOF. If I make the file shorter than 1800 I get an EOF error. If I let it longer I get just 1800 entries.
How can I fix this problem? Where can I say inside the file: hey this list has 2600 entries.
# Read List
set fileName to choose file name with prompt "Please choose log file:"
set myPeople to read fileName as list
set listCount to length of myPeople
log "Count Start: "
log listCount
...
# Save List
set f to open for access fileName with write permission
write myPeople to f
close access f
Technically an AppleScript list written to a disk file, in the manner you have, does not produce a text file, even though you can open it in e.g. TextEdit, or in Script Editor! It's a binary file and when opened in TextEdit, or Script Editor, you'll not see the entire contents of the file.
You need to look at it in a Hex Editor, e.g. 0xED, and the first 4 bytes are 6C697374 or list and the second 4 bytes are the number of items in the list, e.g. 00000A28 is 2600 and 00000708 is 1800.
That said, I'd restore the file from backup and not worry about how AppleScript writes a list to a disk file in the manner you have. I'd also make sure you maintain regular backups!
You can try changing the value of the second 4 bytes, but there is no guarantee it will recover the missing list items, as the file may also be corrupt in some manner or truncated. Backup the file before editing it in a Hex Editor!
Related
I am new to Praat and wondering, if someone can help me to find out, how I can cut all my sound files with a script or anything.
I have like 100 sound files I need for my research. They all have a different length, some are 1 min and others are 3 min long.
I would like to have only the first 22 sec from each sound file.
Thanks in advance!
Kind regards
Olga
The first step is to construct a script that extracts the initial 22 seconds of some specific sound object that is already open. In general, the easiest way to at least start a script is to do a thing manually once, and after you've done that, in a Praat script window, copy the command history (with ctrl-h) to see what the underlying commands are. The manual approach is to look for "Extract part" under "Convert", which corresponds to the command
Extract part: 0, 22, "rectangular", 1, "no"
There is also a command to save a file as a wav file, so you would add that to the core of the script.
Then you need to add a loop that does this a number of times, to different files. You will (probably) need a file with wav file names, and some system for naming the output files, for example if you have "input1.wav", you might want to call the cut-down version "output1.wav". This implies some computation of the output file name based on the input file name, so you need to get familiar with how string manipulation works in Praat.
If you have that much sorted out, then the basic logic is
get next input file name file
compute output name
open the input file
extract from that file
save the extracted file
remove the extract
remove the original
loop until no more files
I would plan on spending a lot of time trying to understand simple things like string variables, or object selection. I left out explicitly selecting objects since it is not necessarily required, but every command works on "the selected object" and it's easy to lose track of what is selected.
Another common approach is to beg a colleague to write it for you.
If I were to give you a file. You can read the file but you can't change it or copy it. Then I take the file, rename it, move it to a new location. How could you identify that file? (Fairly reliably)
I'm looking if I have a database of media files for a program and the user alters the location/name of file, could I find the file by searching a directory and looking for something.
I have done exactly this, it's not hard.
I take a 256-bit hash (I forget which routine I used off the top of my head) of the file and the filesize and write it to a table. If they match the files match. (And I think tracking the size is more paranoia than necessity.) To speed things up I also fold that hash to a 32-bit value. If the 32-bit values match then I check all the data.
For the sake of performance I persist the last 10 million files I have examined. The 32-bit values go in one file which is read in it's entirety, when a main record needs to be examined I pull in a "page" (I forget exactly how big) of them which is padded to align it with the disk.
I have a file on my my desktop called 'file.txt' and it contains the text "test".
When i right click the file go to properties, and view the size it says 4 bytes.
This makes sense because 4 characters = 4 bytes, but the file is called file.txt so this does take some space right?
It only says the file takes 4 bytes and nothing more.
I have tried searching on the web but i could not find a answer to this question.
So how many bytes does a file called 'file.txt' with the text "test" actually take?
The size of a file is given by its content. In your case "test" is 4 chars in length = 4 Bytes. Obviously you will end up with this size regardless of the filename.
The name of a file is stored into directory information structure, which depends entirely on the filesystem in question. For more information on this topic you can consult https://unix.stackexchange.com/questions/117325/where-are-filenames-stored-on-a-filesystem
It depends on your OS. The OS does not store file on a byte by byte basis. A file has to fit into one or more blocks. The most common block size is 4KB. thus your file will take up 1 block on the HDD, whatever that block size is on your specific system. As to where the filename is stored, that depends on your filesystem. FAT, NTFS, ext3, HFS, etc. all have lookup tables/structures to store the name and other metadata. The details are outside the scope of this answer
I am currently trying to write to different locations of a pre-allocated file.
I first allocated my file like so:
File.open("file", "wb") { |file| file.truncate(size) }
Size being the total size of the file.
Afterwards I receive data of XX size which fits into Y location of that file. Keep in mind this portion of the process is forked. Each fork has it's own unique socket and opens it's own unique file handle, writes to the file, then closes it as so.
data = socket.read(256)
File.open("file", "wb") do |output|
output.seek(location * 256, IO::SEEK_SET)
output.write(data)
end
This should in turn allow the forked processes to open a file handle, seek to the correct location (If location is 2 and data_size is 256, then the write location is 512 -> 768) and write the chunk of data that it received.
Although what this is doing is beyond my comprehension. I monitor the files size as it is being populated and it is bouncing around from different file sizes which should not be changing.
When analyzing the file with a hex editor, where the file data header should be at the top is filled with nullbytes (like wise with 1/4 of the file). Although if I limit the forked processes to only write 1 file chunk and then exit the writes are fine and at their proper location.
I have done some other testing such as dumping that part locations, and the start locations of the data and my equation for seeking to the correct location of the file seems to be correct as well.
Is there something I am missing here or is there another way to have multiple threads/processes open a file handle to a file, seek to a specific location, and then write a chunk of data?
I have also attempted to use FLOCK on the file, and it yields the same results, likewise with using the main process instead of forking.
I have tested the same application, but rather than opening/closing the file handle each time I need to write data in rapid succession (transferring close to 70mb/s), I created one file handle per forked process and kept it open. This fixed the problem resulting in a 1:1 duplication of the file with matching checksums.
So the question is, why is opening/writing/closing file handles to a file in rapid succession causing this behavior?
It's your file mode.
File.open("file", "wb")
"wb" means "upon opening, truncate the file to zero length".
I suggest "r+b", which means "reading and writing, no truncation". Read more about available modes here: http://ruby-doc.org/core-2.2.2/IO.html#method-c-new
BTW, "b" in those modes means "binary" (as opposed to default "t" (text))
I'm working on Windows XP and I need to make a script that would compare 2 files (1 on a server and 1 on a client). Basically, I need my script to check if the file from the client is different from the server version and replace the client version if it finds a difference (in the file itself, not only the modification date).
As you suggest, you can skip the date check as that can be changed without the contents changing.
First check that the sizes are different. If so, that may be enough to conclude that they are different. This can have false positives too though depending on the types of files. For example a unicode text file may contain the exact same content as an ansi text file, but be encoded with two bytes per character. If it's a script, it would execute with exactly the same results, but be twice the size.
If the sizes are the same, they may still contain different bytes. The brute force test would be to load each file into a string and compare them for equality. If they are big files and you don't want to read them all into memory if not necessary, then read them line by line until you encounter a difference. That's assuming they are text files. If they aren't text files, you can do something similar by reading them in fixed size chunks and comparing those.
Another option would be to to run the "fc" file compare command on the two files and capture the result and do your update based on that.