Hi,
I was recently using UltraEdit on Windows 10 to handle a tremendously large binary file (~50 GB, a core dump from a memory-intensive process that I couldn't let run to completion). Due to the size, I used all of the suggestions here, meaning I was viewing the direct memory and not a copy.
My aim was to extract a particular ~2 GB section for further processing. However, since this section was about 40 GB deep in the file, the "goto" command didn't work (it can seek to at most byte 0xffffffff, and my target began well past that point). As a coarse first step, I made a selection ranging from a point before the target segment to a point after this segment and ran "Save selection as file," knowing that in the saved file both endpoints would be in the first 0xffffffff bytes and I could then extract the section my program expected to analyze.
However, the file that UE created was empty. Confused, I thought it might have had an issue with my selection, as sometimes with large files the highlighted portion isn't an accurate reflection of the true selection. I began the same procedure a second time, but before selecting anything UE froze and claimed "not responding." I let it hang for a couple minutes before closing it. It said unsaved data might be lost, but I was confident nothing I had done would actually modify the file.
Upon reopening it, the target section was no longer there. The latter ~20 GB of the file was overwritten with 00 bytes, signaling something was corrupted. The other file was still empty. The target section was lost and likely unrecoverable (I've been trying..).
Whether this is entirely my fault for quitting the non responsive process or it's the result of some other bug, I would at least like to suggest a change for the "Save selection as file" feature. If possible, the created file shouldn't be visible to the user until the selection has been copied in, and not created if unsuccessful.
However, I feel it is possible that the issue lies in the handling of any file contents past byte 0xffffffff. It seems not unlikely given the behavior of "goto" that many built-ins are simply not equipped to handle bytes 0x100000000 and beyond, and that my trying somehow caused the program to misbehave and altered memory.
After the fact, I wrote a script in python that easily extracts a specified section of arbitrarily large files with no 0xffffffff byte restriction, but unfortunately had no valid file to run it on by that point. I do like UE's environment, but this problem cost me the result of ~1 week's computation.
I was recently using UltraEdit on Windows 10 to handle a tremendously large binary file (~50 GB, a core dump from a memory-intensive process that I couldn't let run to completion). Due to the size, I used all of the suggestions here, meaning I was viewing the direct memory and not a copy.
My aim was to extract a particular ~2 GB section for further processing. However, since this section was about 40 GB deep in the file, the "goto" command didn't work (it can seek to at most byte 0xffffffff, and my target began well past that point). As a coarse first step, I made a selection ranging from a point before the target segment to a point after this segment and ran "Save selection as file," knowing that in the saved file both endpoints would be in the first 0xffffffff bytes and I could then extract the section my program expected to analyze.
However, the file that UE created was empty. Confused, I thought it might have had an issue with my selection, as sometimes with large files the highlighted portion isn't an accurate reflection of the true selection. I began the same procedure a second time, but before selecting anything UE froze and claimed "not responding." I let it hang for a couple minutes before closing it. It said unsaved data might be lost, but I was confident nothing I had done would actually modify the file.
Upon reopening it, the target section was no longer there. The latter ~20 GB of the file was overwritten with 00 bytes, signaling something was corrupted. The other file was still empty. The target section was lost and likely unrecoverable (I've been trying..).
Whether this is entirely my fault for quitting the non responsive process or it's the result of some other bug, I would at least like to suggest a change for the "Save selection as file" feature. If possible, the created file shouldn't be visible to the user until the selection has been copied in, and not created if unsuccessful.
However, I feel it is possible that the issue lies in the handling of any file contents past byte 0xffffffff. It seems not unlikely given the behavior of "goto" that many built-ins are simply not equipped to handle bytes 0x100000000 and beyond, and that my trying somehow caused the program to misbehave and altered memory.
After the fact, I wrote a script in python that easily extracts a specified section of arbitrarily large files with no 0xffffffff byte restriction, but unfortunately had no valid file to run it on by that point. I do like UE's environment, but this problem cost me the result of ~1 week's computation.
