Update:
Ehh -- Even though this question isn't "answered", I've just emptied my pockets and purchased an SSD. My ramdisk software was going to cost just about as much anyway. I'm not particularly interested in an answer here anymore, so I'll just mark this as "answered" and go on with my life.
Thanks for the help.
I've got a program which is writing files to a ramdisk (in Windows XP) and I need to copy its data from the ramdisk to a directory on my harddrive once it has finished execution. Obviously in a ramdisk the space is limited and I need to free up as much space on the ramdisk as I can between runs. The simple solution is to copy the data folder that my program generates on the ramdisk to a location on the harddisk and recursively delete the "data" folder from the ramdisk.
There is a problem with that solution however; my program looks at the filesystem and filenames to ensure that it doesn't overwrite files (The most recent data file in the directory is 006.dat, so it will write 007.dat instead of overwriting anything). I can't just delete the files once I'm done writing data because it needs that filesystem intact to record data without over-writing the old files when I copy the data back to my hard-drive
I'd like a simple little windows batch script which I can execute after my program has finished writing data files to the ramdisk. This batch script should copy the ramdisk "data" folder to my harddisk and delete all the files from the ramdisk, then it should re-create the filesystem as it was but with all zero-byte files.
How would I go about this?
Could you simply have it delete all files EXCEPT the most recent, then you would still have 006 and your logger would generate 007?
That seems safer than creating a zero length file because you would have to make sure it wasn't copied over the real 006 on the backup.
edit: Sorry can't help with how to do this solely in batch, but there are a bunch of unix utils, specifically find and touch that are perfect for this. There are numerous windows ports of these - search on SO for options.
Robocopy.exe (free download in the windows server resource kit) can do copy from one dir to another AND has the option to watch a dir for new files and copy them when they are closed or changed
Related
Files
I learned from school that operating system deal with directory as file and it contains elements like list of files in the directory and extension of its
so how could I open and edit that file in windows for example?
The operating system does not know exactly how files and directories are stored, only the driver/code for a specific filesystem (ntfs, fat, ext4, btrfs, zfs etc.) knows that.
When you create and delete files like normal you are essentially modifying the "directory file". There is no generic way to edit a directory directly, you have to use normal directory and file functions provided by the OS.
Technically it might be possible to get raw access to the disk and play with the raw bytes but if you do this on a live system you are most likely just going to corrupt it.
I have an encrypted 7z file which has some binary data files.
I am on windows platform (Windows 10 - Customers are also on same platform).
I am using C++ 17.
I am using a third party library (C standard) that can load these binary files only from disk (not from memory streams) into memory.
Loading the bin files from disk to memory takes a few milliseconds.
I don't want to let the users of my software to be able to read the content of the binary files.
I can't use a online service to host these bin files because the customers should be able to use the software on a standalone computer without any network connectivity.
The way I am planning it now is as follows:
Choose a random folder path at runtime (in the windows temp folder)
Extract the encrypted 7z file to the above random path.
Immediately acquire a exclusive lock on the bin files using https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-lockfileex
Read the bin files
After the reading is done, overwrite the files with zeros
Delete the extracted files
Things that can go wrong in the above approach:
Customers having admin privileges can potentially perfectly time the bin file loading in software and kill the process before the files are overwritten.
Customers can potentially get a memory dump and read the data directly (not sure if this is so easy to pull off)
Potentially more ways..
Is there any better way to deal with the situation?
Should I live with the potential of IP loss.
There is a program (program A), that uses some specific file in some folder. Normally that file is on the hard disk.
I need to write a program (program B) that can create such file, but this file should be physically in RAM, not on HDD. So if you unplug HDD, you could not find the file.
I also have no access to program A code. But I want A to interpreting that file as a normal file.
Is it possible in Windows to do something like that?
The only way to have a file that is only in memory is to use a RAM-drive. You can find free RAM-drives and probably some open source implementations but they do require a kernel driver. NTFS mount points will allow you to mount this drive as a subfolder on drive C: if that is a requirement.
From a programming point of view, the only thing program B would be able to do is to set the delete-on-close flag after program A has opened the file. Depending on how A uses the file, you might be able to just delete the file, and if not, B would have to call SetFileInformationByHandle(FileDispositionInfo, ...) on the file handle but this will only work if program A opens the file with the share flags set to allow delete. I have never tested this so I'm not 100% sure it would work if power was lost. NTFS does have journaling that makes sure the filesystem state is correct but I'm not sure if it applies to the delete flag.
I am trying to create a junction point on windows 8 so that files will be written on my HDD (D:) instead of my SSD (C:).
A few of the commands I've tried
D:\Downloads\Junction\junction.exe D:\Temp\Glasswire\service C:\ProgramData\GlassWire\service
D:\Downloads\Junction\junction.exe D:\Temp\Chrome\LocalStorage "C:\Users\Garvin\AppData\Local\Google\Chrome\User Data\Default\Local Storage"
The end result is that files are written to both the junction point directory and the destination directory. My understanding of junction points was that new files would only be written to the junction point directory, but are junction points actually just backup directories or am I doing something wrong here?
(Also I am using Windows 8)
EDIT: From what I see in task manager/Performance only my SSD shoots up in activity when dragging files to C:\Users\Garvin\AppData\Local\Google\Chrome\User Data\Default\Local Storage while the HDD stays at 0%. (I am dragging a 550mb video and 700mb exe from a USB)
I was attempting to reduce the number of writes the SSD performs to increase its lifespan but junction points do not seem to be the way to go, contrary to what is written here http://lifehacker.com/5802838/how-to-maximize-the-life-of-your-ssd
I've always used the built-in mklink /j command to create directory junctions in Windows. It seems to work fine -- just like a soft link in Linux.
Hese's some info from TechNet here: http://technet.microsoft.com/en-us/library/cc753194.aspx
I have found a program that can make you save space by hardlinking files that are actually the same, thus leaving only one copy of the file on the file system with more than one hardlink pointing to it. The program is called hardlink.
This is very nice as I have at last found a way to save space on my backup disk for old backups I have made before I knew about rsync and incremental backups.
After such a lengthy introduction, any reader would expect a question, so here it is:
Would it be safe to use hardlinks to save space on a ntfs partition? The hardlinks would of course be created from Linux, using the hardlink program mentioned above. More precisely, will Windows (any version) be able to then use the files that would have been replaced by hardlinks?
Many thanks
There are hardlinks on Windows. They are created by the CreateHardLink system call in kernel32.dll. As to whether your hardlink program would work over remote shares, I wouldn't know, but a native one or one from cygwin would.
Now the real question is whether or not Windows programs handle them. Even Windows Explorer fails to calculate disk space used for hardlinks correctly.
I did a small test. Creating a hardlink (using 'ln TargetName LinkName') yields the same file at creation time, but after that the file and the hardlink content change independently. I would therefore discourage any use of unix based hard links on an NTFS partition. Use either an Ext4 partition (linux only) or software adapted for windows-like links on NTFS partitioning (windows software or perhaps some linux software if explicitly mentioned).
I guess that the program hardlink will either fail because hard links doesn’t exists on Windows or create Windows shortcuts.