random-access

I have the following fields: Inventory control (16 byte record) Product ID code (int – 4 bytes) Quantity in stock (int – 4 bytes) Price (double – 8 bytes) How do I create a fixed length random access file using the above lengths? I tried some examples online, but I either get an EOF exception or random address values when I try to access them. I tried some more examples and couldn't understand the concept very well. I'm trying a project with it and will try to explore more on it. Here is some example data. There might be holes in the data where No. in stock could be 23 == 023 . Quantity ID. No

Am I missing something or does node.js's standard file I/O module lack analogs of the usual file random access methods? seek() / fseek() tell() / ftell() How does one read random fixed-size records from large files in node without these? tell is not, but it is pretty rare to not already know the position you are at in a file, or to not have a way to keep track yourself. seek is exposed indirectly via the position argument of fs.read and fs.write . When given, the argument will seek to that location before performing its operation, and if null , it will use whatever previous position it had.

This may fall in the realm of "not really feasible" or "not really worth the effort" but here goes. I'm trying to randomly access records stored inside a multi-part gzip file. Specifically, the files I'm interested in are compressed Heretrix Arc files. (In case you aren't familiar with multi-part gzip files, the gzip spec allows multiple gzip streams to be concatenated in a single gzip file. They do not share any dictionary information, it is simple binary appending.) I'm thinking it should be possible to do this by seeking to a certain offset within the file, then scan for the gzip magic

Is it possible to do random access (a lot of seeks) to very huge file, compressed by 7zip? The original file is very huge (999gb xml) and I can't store it in unpacked format (i have no so much free space). So, if 7z format allows accessing to middle block without uncompressing all blocks before selected one, I can built an index of block beginning and corresponding original file offsets. Header of my 7z archive is 37 7A BC AF 27 1C 00 02 28 99 F1 9D 4A 46 D7 EA // 7z archive version 2;crc; n.hfr offset 00 00 00 00 44 00 00 00 00 00 00 00 F4 56 CF 92 // n.hdr offset; n.hdr size=44. crc 00 1E 1B

As AES in CTR mode is great for random access, lets say I have a data source created with a CipherOutputStream in AES-CTR mode. The library underneath—which is not mine—uses a RandomAccessFile that allows to seek to a specific byte offset in the file. My initial thought would be to use a CipherInputStream with a Cipher initialized with the right parameters, but the API for that doesn't do seeking and states to not support mark and reset . Is there a part of the API that I've missed that can do this for me, should I look into the configuration of CTR's IV/block counter and recreate that with a

I have to read the tomcat log file,and after some time(for example:one hour) I will read the file again(just for the new added content),so I create the RandomAccessFile to record the last postion I completed,and use the BufferedReader.readLine() method. However,I found that sometime I can not read the whole line of the file. For example,the tomcat is tring to write the following content(just example): 192.168.0.0 localhost /index.html ..... And at this moment,when I read I may get the result : 192.168.0 0 localhost /index.html ..... or 192.168.0.0 localhost /index.html ..... That's to say,my

I am extremely new to C++ (and programming in general really) and am working on a project that has me stumped (not hard to do ha). The project involves Direct Access Files. We are to create a file consisting of a series of parts records. Here are some of the specifications: Should contain a header record (24 bytes - filled) indicating the number of valid items. Each (24 byte-long) data record will contain a stock number (4 digits max), a description (8 characters max), a count (4 digits), and a "test part" indicator( 4 digits max => -1 - end of file). This file will initially hold 20 blank