Does anyone know of any software that can extract the $bitmap file from NTFS images?
Or does anyone know of any site that documents NTFS enough so that I can code this myself?
(I want to read the $bitmap so I can identify what clusters are not in use, so they can be removed from the images.)
There's one short paragraph in this early publication by a talented person:
http://www.alex-ionescu.com/NTFS.pdf
I answered this one in a different place, but on a live Windows machine the best answer is probably to use FSCTL_GET_VOLUME_BITMAP. This will reflect any changes the FS knows about that aren't on the disk.
There is also "Forensic File Systems" by Brian Carrier. It does explain NTFS in detail.
ntfs.org also is helpful.
Since $Bitmap is a system file, you can't open it up and read it. Also beware that if the disk is in use, it can change.
Related
I am not able to access .DS_store files in High Sierra. Do APFS store meta data of a folder somewhere else, How to read and modify meta data of a folder in APFS.
You should never be reading and writing .DS_store files, they are private to the Finder. Depending on the metadata you are trying to read/write you might use NSFileManager, NSURL, the BSD/Posix functions covered in sections 2 & 3 of the Unix manual (the man) command, AppleScripting the Finder, etc. Time for some reading!
If you don't find your answer ask a new question, show what you've tried (or worked pre-APFS), what you've read, what exact metadata you're trying to read/write, etc. and someone will undoubtedly help you out.
Can anybody please explain to me what kernel level operations are performed, when a file is edited? The thing i'm confused with is that is it the case that a new inode is created every time a file is edited. Please explain the steps, if possible. I have searched the internet, but no satisfactory answers there.
Thanks in advance.
There's no single general answer, because this depends on what the application does when it's editing the file, what system it's running on, and what the file is stored on. It might be creating new temporary files, or clobbering and rewriting the original file, or using memory mapping, or using versioned filesystem features, or doing network file system operations, etc etc.
Instead of trying to answer this in the abstract, pick an open source editor you're interested in, and read through its source code and debug it to understand what it in particular is doing. Then if you have questions, you can read the API docs to figure out what kernel operations the functions it's calling map to or rely on.
I'm trying to identify a file, but it has a header I've never seen before: "Intel_FBF". It's likely an embedded firmware file, but I have no idea.
Sorry, that's not much information to go by. Can you give any other hints about its history, context?
Is it binary, text?
What is the file name, extension?
Where did it come from?
What were you told it's good for?
One thing you could try is the file utility on Linux.
Note: I've tried searching, Stackoverflows near useless. I am not sure what kind of tool I need.
At my organization we need to keep track of the software configuration for many types of computers including the binary installers and automation scripts. Change is infrequent but the size of latest version of the configuration is several gigs.
We are trying to use Mercurial to store changes but it is just too slow, even without many revisions at all. I did an hg status but killed it after it took 10 minutes without finishing.
We are looking for a way to store the current configuration as well as having the old configurations there just in case. I have never done anything like this before and do not know what tools are available or even suitable for such tasks. Can someone point me in the right direction or tell me how the are solving this problem? Thanks
Since hard disk space is cheap and being able to view binary differences isn't very helpful, perhaps the best option you have is to store each configuration in a new directory that is indexed somehow. Example below:
/software/configs/2009-03-15
/software/configs/2009-09-28
/software/configs/2009-09-30
Given the size of your files and the infrequent number of changes, this would allow you to pick a configuration from a given 'tag' without the overhead of revision control.
If you pack your files into a single tar file and generate a SHA-512 hash, then you can be reasonably sure that no one has tampered with your files since they were archived.
While I don't know specific details about how to implement this strategy in mercurial, I have been working with git and git-fat. It sets up a general procedure that is likely to be feasible on mercurial as well. Basically the idea is whenever you add a binary file to the repository, under the hood, the repo creates a symlink to the file that is actually stored in another location as a checksummed object.
This allows large files to be tracked by the repo, without storing the actual data inside. It requires the data to be stored in some other location (perhaps in a binary management system).
It might take some configuration to do it in mercurial, but I think it's an elegantly simple solution.
I am looking at some files generated in the early 90s. One of them seems to hold references to data packed in some binary format in a number of large files.
The first six bytes of the file are 0x42 0x4f 0x53 0x53 0x20 0x37 which spells BOSS 7.
My searches of various sources of file type information, including /usr/share/file/magic have not turned up anything. Does anyone know what software might have been used to generate files that start with these bytes? Any information on file layout would be great.
It looks like the file might have been generated by VisualWorks Smalltalk:
[BOSS 7.5]
Contains the Binary Object Streaming Service, which supports efficient storage and
retrieval of objects, including code, to and from files.
Note that for code storage, the parcel system now supercedes BOSS.
I tried to load the file using the IDE provided at http://www.cincomsmalltalk.com/ and it generated a meaningful exception:
The identifier MediaCollectionDictionary has no binding
The file does contain:
MediaCollectionDictionary
MediaCollection*
CallMediaVehDict2
etc which means, if I could now figure out what the rest of the files do and learn enough SmallTalk, I could disentangle this mess.
Of course, I am not sure if this analysis is correct. So, please if you have any other ideas, let me know. Thank you.
Much later: So, my initial assessment seems to be correct. I got some useful tips on comp.lang.smalltalk: http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/5d55d857e2f80158#
Ask on comp.lang.smalltalk
Ask on the vwnc mailing list