Is there any good way to storing lucene index in db without any external library, that touches connection layer (like JDBCDirectory) and also without using file system (even temporary). RAMDirectory would be fine for me if I could get from it specific parts of the index - .cfs "file" and segment. Don't know if it's doable. Will be thankful for any help.
Related
Our current system database system is a clipper DOS application. The database inside its folder is fragmented/divided into many parts. I want to decrypt the database so that I will have only one database in all and avoid reshuffling of data. I'll attached the file folder Screenshot.. the database is on .DBF format
VScreenshot of files
Often you can decompile the CLIPPER exe file to source code and work from the .prg I've done it many times. The program to use is called WALKYRIE.
In Clipper and Fox Pro for DOS .dbf file is a simple table file.
If You want to use as data base with many tables in one unit.
You can import these tables in MS SQL data base and/or part of a MS Access database.
I see that you got several answers. Most are partially right. Let's address these one at a time:
All those files essentially comprise the "database" for the application you're using. They could be used by other applications as well. Besides having a lot of files, what is the problem you're trying to solve?
People mentioned indexes. You can generally ignore these. There are there primarily to make access to the data files faster. Any properly written clipper application will recreate these if they're missing or corrupted. You could test this by renaming one, running the app, and seeing what happens. If it doesn't recreate it you can name it back. Not replacing missing index files would be unusual behavior.
The DBF file format is binary, but barely. Most of what's in a DBF is text and is readable with an editor. But there's no reason to do so - I'm sure there are several free DBF utilities out there to to read DBF files. Getting the structure of the files could be very helpful.
Getting the data out of the files would also be fairly simple with a utility. If you look up the DBF format you could even write one fairly easily in Clipper, any other language that uses DBF files, or in something like Python. Any language that can open and write files, really. It's not hard - any competent developer could do this in a matter of hours. Must less if you're using Clipper or another language that natively reads DBX files.
Most people create dBase/Clipper programs with relational data, like SQL Server. Where SQL Server has tables that relate to each other dBase/Clipper has a file for each "table." This isn't a requirement, but it was almost certainly done this way.
Given that, if you get the table structures through a utility or by reading the headers in an editor (don't save them from an editor!) you could quite likely recreate the database schema (i.e. the map of the data). Once you have that it's fairly trivial to get the data into another type of database (SQL Sever, Access, or whatever you like to use.) If non of the files are too large it's conceivable to put all the files into Excel sheets. It really depends on what you want to do with it.
As others have said, you may be able to get the code by Valkyrie. Some people have used it very successfully. I don't know where you get it and I've never used it. Why do you not have the code? If this is a commercial application you likely should not have it. If it's a custom app who ever wrote it or paid to have it written should have the code.
Again, it's not clear to me what problem you're trying to solve. But there are many options for doing something with those DBF files. Fortunately they are one of the easier to read data formats you could be working with.
Let me know if you have any questions. Apologies for the typos that are no doubt scattered throughout this reply.
You sort of can get an idea of how they relate to each other by opening the index files they use (.NTX files). If you have the DBU utility (executable) around, you can open the DBF and load the index (NTX). LibreOffice Calc is also able to open DBFs (haven't tested .NTX).
If you open the .NTX on a text editor you will see the indexes in the beginning.
I open with Access, but I can save the data using a PrintFill Program.
Development environment: mobile app in Android
I'm looking for a way to uniquely identify files in a FAT32/VFAT file system (which has no inodes).
I thought about hashing (SHA1?) the full path. The problem with this solution is that it doesn't support moving/renaming.
Is there something better, that will hold even when moving/renaming the file?
Thanks
Unfortunately FAT doesn't have Unique file IDs and when they are needed, various system components emulate them by maintaining the list of all files of the filesystem in memory (thus the ID is unique and valid only when the system is running).
Depending on what you control (either you have a filesystem driver, a filter or just a user-mode application) potentially you can do the same - have a list of files and provide some unique ID based on that list.
I'm making app with ~200 text files, each file contains ~50000 symbols (it will contain more files later). App will work offline, so text must be prepopulated. First thing about which I thought was usage of databases. But after I googled, I found that it's currently not possible to access SQL prepopulated databases in Phonegap without writing native code and other databases max sizes are too small for my needs.
I need only to read data (writing isn't necessarily).
Is it possible using database?
Is it ok to use JSON/XML/HTML/other file or separate files to store needed text? Won't it cause performance problems?
Is there more suitable approach?
I'm trying to identify a type of file that contents starts with "[CS Format=A]".
I've extracted files from blobs from a database I was handed. I do not have access to the software that created this database. There is a column that I assume signifies compression (it's called COMPRESS). Also in said database were the names of the files and their extensions. I've extracted all the files out of the database and everything works except anything that's marked as compress is not readable as it's own file type (I.E. if it was a PDF before it was stored in this DB now that I've pulled them all back out it is not parsable as a pdf like the other non-"COMPRESS" pdfs). When I crack them open and look at them the first 13 bytes always are "[CS Format=A]" (which I swear I've seen somewhere before, but can't for the life of me remember what) followed by binary data. Magic can't tell me what I'm looking at and google is not being very helpful with my very strict search term. These were stored in an MSSQL database before I was given the files, most likely 2005 by the time it was pulled.
Probably not helpful, but just to make sure... Oracle will decompress automatically on select.
If it's still compressed afterwards then you're looking at some 3rd party component which can be almost anything, but I'd start with testing Mac/Win first before you run through all the 3rd party compression tools.
For Windows.Forms, I have an application that needs to get a unique install id for each install from my server, and then persist this data so once registered, the install ID is included on all communications back to the server. The application is in occasional contact with the server.
How can I persist this data on the client in a way that is not easily tampered with?
First, you should note that if the data is on the local file system and your application can read and write it, it will always be possible for a determined user to tamper with it... perhaps not easy, but possible nonetheless.
That said, there are a number of options you could consider, including (but not limited to) :
encrypting the data with a key defined in your assembly : pretty safe is the user has no programming skills, but an advanced user could disassemble your app to find the key. Obfuscation could make it harder to extract the key, but not impossible.
using an isolated storage : I'm not sure whether the data is encrypted or not, but at least it's not easily found, hidden in a deep folder hierarchy... Not so safe is the user knows where to look, however
writing the data in a binary format, which makes it harder to read or modify for a non expert user
using a piece of native code to encrypt the data : similar to the first option, but a native DLL is harder to disassemble than a .NET assembly, so it requires more skills to find the key
Again, all these approches are not bulletproof : as long as your program can access the data, an advanced user could always reverse engineer it and do the same...
You could save the data in the windows registry. You'll use the [HKCU\Software\YourAppName] hive key if it's a per-user setting, or [HKLM\Software\YourCompany] if it's a global setting. However, the data would need to be encrypted, because its trivila to get the values in these keys