Original modified #9
Conversation
|
The only useful change would be to update the |
|
After cloning and trying to build it with Delphi 7 enterprise the following happens: Project RamDiskUI/dpr:
To fix this problem I add all units from Tnt Unicode library. (Instead of using search path, I like adding files to the project to actually see them in project manager and have more control/access to the, and prevent anything weird from being on the search path and also avoid losing settings when changing IDE through time): Example: uses Now I assume you think this will build in Delphi 7 ? But it doesn't for some reason: [Error] RamSync.pas(306): Undeclared identifier: 'WidePosEx' So now we have two programmers with two different believe systems:
I suspect the discrepancy is with the tnt unicode download... maybe something changed across time to this library leading to this build failure.
Another weird thing: The virus total scanner reports 2 malware indicators in the release version... possibly command and control functionality ? I have not yet repeatable an exacty re-build... so far only debug build, size is different ofcourse. It would be interesting to know which exact version of Delphi you used to make the release version, which build settings, maybe even which tnt unicode library version/commit. To see if I can also reproduce the exact same exe. Failing that ghyndra may have to be used to reserve engineer the exe to see if there is any malware in it ;) :) For now I have build from sources, installed the service.exe. Seems to work, however I do notice a shutdown failure on my system, but I believe this may be related to nvidia driver bug. I tested shutdown today, without gaming but with ramservice.exe running it shutdown proceeded smoothly/normal. Concering AI code editing, it did look different to me first time I looked at it, maybe I look again it, would be helpfull if you posted exact code which you mean is similiar, I think I know what loop you referring to, to me it did look different, but didn't really study it that much. I must go sleep now, but this is what I could do for now. Oh one last thing, I tried to modernize the code by having the AI switch to unicode/W versions of API. So far seems like "total" failure. Gemini had big troubles concerting: Set of 'A' to 'Z', something like that. Delphi translates this into a set of unicode char, no way to change this to ansichar ? This might be a real Delphi language problem/limitations. Not sure yet, compiler seems to suggest to use CharInSet to try and solve it. These kind of char/string issues ansichar vs unicode is very troublesome and annoying in Delphi and definetly a case of "broken delphi language"... could be worth sending an e-mail to embar... to try and solve this somehow, not sure if they will be interested. One other crazy thing I noticed is Comparing PWhatever to Pwhatever2 not possible. Can't compare pointer types... hmmm another kinda ouch, but nothing real-world, just synthetic case: if Ptype1 = Ptype2 then, not possible in Delphi 12.3 I did this to see what would happen if WinApi.Windows is copied to WinApi.Windows.V2, no complaints from Delphi, two exactly the same units can be used as one can "overrule" the other. This is basically what some code/constants in your units are doing.... so I was wondering if there is a way to detect which constants are now duplicate inside windows api and which ones are not, but could not do it this way. I also made the gemini develop this tool from scratch it went fast, but again not yet a cooklie, somehow failed... maybe device name problem. Also this project requires a manifest/override security settings + it running constantly as a service makes it a bit suspicious/risky ;) AI managed to find headers for driver on web that was kinda amazing, translated them fast, also amazing. I do wonder how your tool fast the ramdisk ? because with just driver and batch files this would be difficult... volume has no name or something ? AI suggested some heuristic to find it quickly... AI also suggested to use robocopy to copy files/back and forth... instead of more complex custom code... I am kinda in favor of custom code, less dependencies. AI mention your code had a bug in it, it was skipping a line index ? Maybe I should have copied it's entire feedback, but maybe it cost lost or something during the dev process... maybe it would have been obvious to you or during a debug session, have not tried it yet, not sure how to trigger this code, since it's dealing with service, not sure if it's safe/crashing system or how to do this interaction etc. Anyway I gave up on trying to get it working in Delphi 12.3, so I switch to Delphi 7 under Windows 11. Discovered that win32hlp system is actually nuked by Microsoft, no longer available to Delphi 7 help files not working, it is possible to reinstall win32hlp from unofficial sources, but not advisible, makes system vunerable to *.hlp attacks. I was kind of a blast from the past to see Delphi 7 run again. Amazing it still works on Windows 11, I thought I'd seen a version that didn't work anymore, guess I was wrong... or maybe it was just one of the executables produced by one of these Delphi compiler versions, anyway, so far so good. Also d7 enterprise seems to generate diagram portfolio files, *.dpp or something, kind of a mystery, modelling I guess, but couldn't find a way to see/view/enable it to see them, kinda weird. I can remember seeing modelling support, probably for UML, but can't remember which Delphi version it was that had this. I think probably D2007, but apperently D7 might have had it as well, at least enterprise version (?!) Well, thanks anyway !, I am now using this product on a daily basis, saves me some work. I do wonder if it truely copies all files on shutdown, the shutdown seems a bit fast, but so far so good, maybe it copies them while idling ? lol, probably not... hmmm... kinda strange ! ;) I did put a little test file on it, it was stored I believe, but I may have to do some bigger testing... no man overboard if it's not flawless, so far using it only for firefox webbrowser, but would be nice if it is flawless, then could be used for other purpose. Today I also learned Windows 11 has a feature called "Sandbox", I will try that soon too, could be interesting for AI purposes. Seems like my brain is a bit rusty from lack of Delphi usage and lazyness from AI usage :) If I do find a bug in this code and the AI was correct about it I may return to this topic to bug you up your arse once again lol :) |
|
OK, I had gemini analyze the "SaveSettings" part of the commit and it's associated bug, it's a small one but here it is: In short I guess your code assumes there is always at least two characters at the beginning of the string: C: It's also kinda interesting to note that gemini kinda writes risky fix code, assuming boolean evaluation is "short" while in reality it might be enabled as "long"/"full". It also confirmed the loops are identical, but I probably was not referring to that loop when I saw gemini mention some loop error. (The other code will be examined below this one) Concerning the more complex code. Here is what Gemini has to say about it. I quickly ran this test program, it does seem to generate some range check error, I simply moved the WidePosEx function below it and renamed the call ot WidePosExChar, not sure if this is the correct function to use, as the original is missing as far as I am concerned, however digging deep into Tnt Unicode library might find it... maybe it was removed during it's evolution... So far nothing to concerning. However my system keeps hanging on shutdown... I suspect RamService.exe has something to do with it so I will ask gemini to analyze it to see if it can find a reason for it. I suspect the hang only happens after the RamService has been running for a while... Explanation of the Bug in the Old Code The primary bug in the old SplitPath procedure lies in how it handles the oldPos variable and the Copy function. The Fixes in the New Code The new code correctly addresses these issues: Delphi Program Demonstrating the Bug and Fix This program defines both SplitPath procedures and a demonstration function TestSplitPath. It will output the results for a few test cases, clearly showing the incorrect output of the old code and the correct output of the new code. |
…k detachment. The RamService was observed to cause hangs during Windows 11 shutdown. The hypothesized cause is a race condition with the Service Control Manager (SCM). The `DetachRamDisk` function, called directly during `ServiceStop` and `ServiceShutdown` events, can be a long-running operation. The SCM imposes a strict timeout for services to respond to control signals. If the service fails to respond promptly, the SCM forcibly terminates it. This premature termination likely left the RAM disk in an unstable state, causing the OS shutdown process to hang while waiting for a resource that was not cleanly released. This commit refactors the service's shutdown logic to prevent this timeout and ensure a graceful exit: - **Introduced `TShutdownThread`**: A dedicated thread is now responsible for executing the `DetachRamDisk` function. - **Asynchronous Shutdown**: On `ServiceStop` or `ServiceShutdown`, instead of detaching the disk directly, the service now creates and starts the `TShutdownThread`. This allows the main service thread to remain responsive and acknowledge the SCM request immediately. - **Graceful Wait**: The main `ServiceExecute` loop, upon termination, now safely waits for the `TShutdownThread` to complete its execution. This guarantees that the RAM disk is fully detached and cleaned up before the service process exits. - **State Management**: The `FShutdownThread` handle is initialized to `nil` on service start to ensure clean state management. This change ensures the service signals its compliance with the shutdown request in a timely manner while allowing the potentially lengthy disk detachment process to complete safely in the background, resolving the system hang. - (Note: RamService.dpr assumes a .\bin folder exists for outputting the binary, if this bin folder does not exist, the build might fail, either user must create bin folder or adjust project settings and remove bin from project settings.) - First initial improvement, however, the system could still hang during long operations. The solution would be to periodically inform the system the shutdown service is still busy. These improvements will be attempted in a next commit.
The RamDisk service could hang or be terminated prematurely by the Service Control Manager (SCM) during startup or shutdown. This was because the service did not report its status while performing long-running operations like creating or removing the RAM disk. The SCM would interpret this lack of communication as the service being unresponsive and would terminate it. This commit addresses the issue by implementing proper status reporting in `SrvMain.pas`. The `ServiceStart` and `ServiceStop` procedures now: 1. Set a `WaitHint` of 60 seconds, providing a generous timeout for the operations. 2. Periodically call `ReportStatus` with an incrementing `CheckPoint` value. This ensures the SCM is kept informed of the service's progress (SERVICE_START_PENDING, SERVICE_STOP_PENDING) and prevents it from incorrectly flagging the service as hung, thereby improving service stability and reliability.
Looks like I as not completely correct in the README - it turns out I am actually using TMS UNICODE v2.1 which does have the
Yes, the TMS Unicode library must be downloaded and installed. It is not included in this repository because it is not a code written by me. But I have now included the
If you do not trust my EXE - you are strongly encouraged to compile your own. Or you can disable the network access for that EXE in your firewall.
Already mentioned TMS Unicode v2.1 (latest version is 2.5.0.1) which was bought by TMS from the original author Troy Wolbrink (https://www.yunqa.de/delphi/products/tntunicodecontrols/index) The build settings are in the corresponding CFG and DOF files (e.g.
Troubleshooting will be problematic, especially without enough details.
Which are these API functions that you need to be Unicode? There is definitely no need to make everything Unicode - just the parts that actually need to be.
Delphi's
Comparing PWideString to another PWideString is definitely possible - but it compares pointer values rather than null-terminated strings. Comparing PWideString to PWideByte obviously does not make sense and needs explicit type-casting.
Can you be more specific?
The manifest seems to contain a leftover from copy/pasting it from another project - the word
I have to admit that I have difficulties understanding what you are trying to say. I am not using any driver headers (I do not need to link the driver as DLL) - just calling the driver's API directly.
Robocopy could be used when populating the RAM-disk at boot (if configured for this) - but I am not sure whether it supports folder exclusion when persisting the RAM-disk at shutdown because I want to have/offer the feature of not persisting e.g. the TEMP folder. Anyway, the current code works like a charm.
No idea about this unless you can describe the steps for reproducing this bug.
I am sitting on Win7 and have not experienced such attacks yet.
DDP stands for Delphi Diagram Portfolio - it is not created automatically, you must manually (if needed) drag components in the diagram to document your design (e.g. to show the parent-child relationships between DB-aware components)
On theory Windows must wait for it to complete but it is possible that if Windows thinks it is hung, to use a timeout and not wait too much. Possible on theory but have not seen it in practice. Probably because I tend not to persist too much files - the feature is just in case I have downloaded something during the day on the RAM-disk and forgot to copy it on a non-volatile media before shutting down :)) But I do not want all the other disposable stuff from my workday to be persisted.
That was my primary goal, too - to use it with Chrome and avoid the gazillion of cache and temp content which both websites (service workers or IndexedDB) and browser itself tend to constantly create and thus avoid wearing out my SSD.
You are correct - it would be safer to first check the length of the string before indexing. Accidentally, I am actually using single-character strings in my config and have not experienced an exception or access violation: But that's because in my case
I am using it daily for at least 4 years and have never experienced such hangs. Although I have seen uTorrent to be forcibly closed by Windows on shutdown.
To be honest, I do not remember why this function is there since it is not used by any other part of the code. Most probably that's why the bug stayed undiscovered. Will remove this unused function. |
|
I have not read your latest post/message, I will do so later. Meanwhile I have updated this pull request, with 2 new commits, which attempted to give the driver/service more time to do ram loading/storing from/to disk, by using a seperate thread and informing SCM that service is pending/busy and giving it 60 seconds time out. However AI reports SCM might close things within 30 seconds, depends on OS/registry settings. Even if it were 30 or 60 seconds, this solution seems unstatisfactory to me. I tried to get the AI to do more code edits and add proper thread to by-pass/run in parallel to whatever the ramdisk is doing, but that kinda failed to really work, instead the AI started injecting more call/checkpoints it did create some additional thread or whatever, but ultimately the code was problematic: missing handle to service. I could post it later, but for now keeping it to myself, I don't want to post broken code for now. Though the extra inject points were interesting, but again doesn't solve the problem completely. However the newer/unpublished code did work around the potential delphi bug. At least I will post that section so it can be re-used later, if tried again, it was also seperated into seperate unit, makes compiling it a bit easier: Seeing these potential bugs in Delphi 7 made me run scared ;) I will re-attempt a translation to Modern Delphi 12.3 hoping that this might solve some of the problems/limitations, maybe a fools attempt, but I try it anyway. This time a more thorough (spelling?) approach was taking: Functionality description of source code so far... then re-creation into V2... trying this now. Depending on success/failure, I will either proceed with modern delphi 12.3 attempts or fall back to Delphi 7. |
|
OK, now I have read your latest message, thanks for responding it clearifies some things. First let's start with my current Delphi 7 Enterprise edition, it seems slightly different from yours: 
(Concerning this picture, at first I thought it said 7.C believing it might be newer than yours, but now that I look at it again it seems the ( is cutting of the zero, creating a false C ? not sure, changing dpi settings might shine more light on this, the build numbers however seem radically different: build 8.1 vs build 4.453 ????) Second let's continue with the TnT components, if the ones you are using are not "free" then this will be problematic for users to compile your project... Third I made a little typo: Wrong sentence: I ment to write: Correct sentence: I do wonder how your tool MATCH the ramdisk ? because with just driver and batch files this would be difficult... volume has no name or something ? AI suggested some heuristic to find it quickly... Anyway, I've asked the AI to make a functional description of your tool, including safety risks with the RAMDISK formatting/detection, according to the AI it seems safe which is good to know ! I will post this functional description in a next message. |
|
This may help to refresh memory or to help others to try and understand this project, especially how the RAMDISK is created/detected/formatted safely: ✦ I've reviewed the README.md file. It seems this is a Delphi 7 project that provides a GUI and a Windows service for the
Core Logic Units Both Main.pas and SrvMain.pas rely on other units for the core RAM disk operations:
Project Understanding: RamDisk Support Utility1. High-Level GoalThe project is a GUI application and an accompanying Windows service designed to manage the Arsenal Virtual RAM-disk driver. Its primary purpose is to provide a user-friendly interface for creating, configuring, and persisting a RAM disk, similar to the popular ImDisk Toolkit. The key features are:
2. ArchitectureThe project consists of two main executables:
Configuration is shared between the GUI and the service via the Windows Registry under 3. Core Implementation DetailsThe application is written in Delphi 7 and interacts with the underlying Windows systems and the Arsenal driver at a low level.
4. Dependencies
Project Source Code Summary This document outlines the functionality of each source code file in the RamDisk Support Utility project. RamdiskUI.dpr
RamService.dpr
Main.pas
SrvMain.pas
Definitions.pas
RamCreate.pas
RamRemove.pas
RamDetect.pas
RamVolume.pas
RamSync.pas
RamSetup.pas
Junctions.pas
Safety: The risk of formatting the wrong drive is the most important safety consideration for a utility like this. Based on a detailed analysis of the source code, the risk of this utility misidentifying the RAM disk and formatting the Here is the step-by-step process the utility uses, which ensures it targets the correct disk:
Conclusion The utility does not guess or rely on fragile methods like "the last disk that appeared." It uses a specific, unique The only conceivable (and astronomically unlikely) failure scenarios would be:
These scenarios are outside the control of the utility's code, which appears to be written defensively and correctly. |
|
Concerning the Delphi 12.3 vs Delphi 7 situation. I would be very much interested in a version of this tool for Delphi 12.3 so I can work with Delphi 12.3 instead of Delphi 7, even though I do like Delphi 7 a lot. (I might even try and obtain a copy of Delphi 2007 as well, that would basically give me all 3 essential delphi versions. Delphi 7 for win95/win98 era, Delphi 2007 for win xp, Delphi 10.3 for windows 7, Delphi 12.3 for Windows 11). Another benefit might be bug fixes in VCL/RTL of Delphi 12.3, ofcourse new bugs could exist as well. Another adventage could be using slighter newer VCL or even Firemonkey in future. May main worry is that this project might be lost in the future if something changes in future versions of windows... maybe the ansichar/ansi string versions of API removed, or 32 bit windows support removed, things like that. So for that reason a Delphi 12.3, 64 bit version of this tool and driver would be preferred/smart for future use. Perhaps only the newer unicode APIs of windows 11 are fixed... perhaps older ansichar/ansistring apis will not be fixed by Microsoft. So for me it's also trying to stay recent, trying to avoid any potential issues/bugs in older APIs/code paths, ofcourse the opposite could happen to, newer APIs could have buggy behaviour as well. I am surprised that you have not yet witnessed the shutdown hang, which makes me doubt my hypothesis that the ramdriver/service is at fault. My ramdisk is currently 2 gigabyte for firefox, how big is your ramdisk ? :) Also a difference between you and me is that my ramdisk writes back to harddisk instead of SSD. That could explain why my system is taking longer to do so... however the shutdown seems quite fast, just a few seconds, so maybe there is more to it. Or maybe something else is the cause. But a shutdown of a few seconds could indicate that the ramservice is being aborted/terminated before proper writes, so that is also a little concerning. What I could do is create a large RAMDISK of say 100 gigabyte. Then put files on em like 1 MB files or 1 GB files, maybe modify them in memory/on ram disk to make sure they are different, then shutdown the system, theoretically this would take pretty long, like minutes to write back. 100 GB / 180 MB/sec = probably something like 10 minutes roughly. These files could be created on ram disk only, to prevent them being on disk already, this should force the ram driver to write quite a while while shutting down. Unless this ramdisk service already writes a little bit during usage ? but I do not believe it does so, and windows is probably not smart yet to understand :) At least this would then shine some light on if the ram disk service is functioning correctly or if files are being lost. I guess I should start with this, but was kinda boring/lazy to do, but I must now confirm this issue to be real before proceeding I guess, otherwise wasting my time, but not entirely. There is the possibility that something else is causing shutdown hang, like buggy nvidia driver. My system has 128 GB of RAM, not sure what your system has ? Because the problem is on my side and not on your side, it would make more sense if you try and re-create this problem safely on your side. For example create a new ramdisk, with many little shitty files, then instead of writing it back to SSD, try writing it back to a harddisk ? Ofcourse if you don't have a harddisk this would not be possible. One alternative could be to simulate the harddisk writing and simply build in a long sleep of a few minutes or so to see how windows behaves. At least this would tell us if windows 7 is behaving ok together with this driver. This could isolate a potential bug in windows 11 itself, though speculation for now... Another idea which I first want to explore is simulating shutdown behaviour with SCM, maybe Microsoft forsaw this problem and there is a way to simulate shutdowns... plus I also want to install sandbox feature of windows 11, might be a smarter/better way to test these things... so I am not yet ready to write huge files to/from ramdisk which might be buggy, not sure what is going to happen for now it's probably not buggy enough to cause any issues, but would like to dive a little bit deeper before attempting this, might save some time, or maybe have to dive deeper into it anyway, have not yet made up my mind, so for now more code exploration, until I am more or less certain it's not the source code/driver at fault... So for now I have no way to be sure which is causing the shutdown failure, it's kinda hard to simulate... it also doesn't make much sense to me. Why would a quick boot/shutdown cycle not cause problems and a longer boot/shutdown cycle after browser usage does cause shutdown hang ? The only thing I can think of is that your ram service detects changes between the files on both disks and only writes the necessary changes or something from ram back to disk, that could explain why it might take longer... so I would need to confirm this hypothesis a little bit... However here is the strange bit: there is no disk activity after a few seconds, so that is why I believe performing this ram to disk write test is useless anyway.... so that is why I am focussing my time on trying to find any bug in the code itself... Though a bigger write test might still shine some light on it, but I just don't believe in it for now, making me feel like I waste my time on it. But at least I can ask AI to write a test program to generate these big files on ram disk... However the AI has detected enough problems with the original code to try and fix those first anyway... Plus debugging it seems to be a better approach than just wild guessing, so I am trying to get this code into a state where I might be able to debug it better with Delphi 12.3. Delphi 7 seemed to maybe have some debugger issues, not sure, it warns that it wants to install some hooks or something, but maybe this is related to remote debugging... Delphi 7 is so old, it does not feel safe to use this for debugging on Windows 11. Plus I also do not want to do unnecessary boot cycles on this computer, plus if something really strange is happening I have no idea would could truely happen so from safety perspective seems better I try and figure out what is causing the shutdown bug... Basically the monitor goes dark, the system stops responding, the gpu leds/cpu leds stay on, so I have literally no idea what it is doing, so I find that situation a bit scary, hence my reluctance to do any kind of crazy write tests while the system is in a very weird state ;) :) However this is a bit hypocrit because tool might already be doing some writes, but 100 GB writes... hmmm... I have to be really sure it's not going to overwrite anything big... so I'll think about if I want to do these tests. A safer test, could be introduce a sleep or maybe some beeping or something to know what it's doing... |
Will take a look at this later.
It will close if the OnStart of the service does not respond to the SCM within 30 sec (this default can be changed through registry) that the service has started.
It will only happen if pre-filling on boot or pesisting on shutdown takes more than 30 sec. Unlikely to happen in most situations but I agree that a separate thread on boot is a better solution. However, background thread will not solve the problem on shutdown - because as soon as the service reports to SCM that it has finished, kernel will continue with the shutdown and not wait for the background thread to finish the persisting. The simple (and probably naive) workaround is to never copy too many data from/to RAM-disk on boot/shutdown. In my case the amount of data is less than 400kB.
Not sure what exactly are you trying to achieve here. Service creates the RAM-disk on boot, moves the system-wide TEMP folder if configured, pre-loads some data if configured - then waits for the shutdown signal without doing anything.
What bug is this?
It might be possible to use FreePascal / Lazarus instead of Delphi 12.3 - but this will probably also need some tweaking of the current code.
You probably need to install the first update (service pack) - there are 3 in total for Delphi 7.
I agree. Can you check that you are able to compile the new code with the free version?
Again not sure what do you mean. The service creates the RAM-disk on boot (or the UI creates it on the fly - if you do not use the service) as an SCSI device, then creates a partition on this device, then creates a NTFS filesystem on that partition, then formats that filesystem, then creates a TEMP folder if required, then changes the environment variables, and finally pre-loads the RAM-disk with the specified folder (from another disk drive, obviously)
Basically, the method is a simplified version of the same method that the own CLI tool from Arsenal does it. Looks like you already produced an explanation of the code from the AI.
Might benefit you if you intend to develop other projects in Delphi in the future. Otherwise highly unprobable to see fixes that are relevant for this particular project.
Honestly no idea why would you need or want Firemonkey instead of VCL for this particular project. But it is your choice.
If M$ decides to break some backwards compatibility if will probably affect some insignificant amount of users. Even now there is not a small number of users who are still using Win7 and have no intention to change it. If this project ceases to work properly on some newer Windows version - I definitely won't use such version of Windows :)
Most likely will force some amount of users to switch to Linux or MacOS. No idea how many users, though.
I guess the driver is already 64-bit and the tool can probably be compiled with FreePascal as a 64-bit executable.
What fixes do you need? I mean - what problem are you facing that needs fixing?
Not a primary priority for me. If someone finds a bug in my code - I will try to fix it. If there are no bugs - I will use the code forever because it just does the job. I had a former colleague who was obsessed of being recent (probably still being) - everyday updating almost all of his software. Sometimes taking an hour or two of his workday. Meanwhile I was using "not so recent" soft without any issues and used my workday efficiently.
If you are not persisting the RAM-disk - probably something weird in your Windows like a particular update or particular registry setting, who knows? After installing some update on my Win7 (unfortunately I have no clue which one exactly) I now experience this weirdness that the keyboard layout tends to often change to non-English (to my native language) on its own, randomly - usually when switching between applications with ALT+TAB. It's really annoying.
It is 16GB because I usually put the
It very much depends on how much data is being written. For me it is almost always zero - unless I have forgotten some PDF book(s) or some Youtube video on the RAM-disk.
Quite possible. You can measure how much does it take to copy your files from the RAM-disk to the HDD - while you are normally using it.
In such case Windows supposedly should log the timeout in the EventLog. Have you checked?
Definitely. I would not leave such large files on the RAM-disk when it is configured for persistance. The only reason I am using persistance is just so I do not lose some file that I downloaded from somewhere (and put on the RAM-disk to evaluate before deciding whether to keep it or delete it) that I do not remember the URL at the end of the day.
It does not and must not because this defats the purpose of the RAM-disk to prevent wearing out the SSD.
I am even remotely incapable of guessing what the cause might be in your case ...
64 but never used even half of them.
I am pretty sure that if you try to persist 1+GB file on a slow spinning disk - it will probably time out and Windows will try to forcibly shutdown. If instead Windows is hanging and not shutting down - then most probably there is some infinite loop Why do you need to persist so big amount of data off your RAM-disk? On theory, RAM-disks are supposed to be volatile - and only used for speeding the work and then tossing off the data.
I think it will be easier if you try a VM like VirtualBox or VMware or even ProxMox. Or maybe you can experiment with some other RAM-disk software, e.g. ImDisk ?
Can you try without persistance if there is still a hang?
The code excludes the folders that are marked for exclusion, then (if the checkbox is ticked) first removes those files from the persistent folder that are no longer present on the RAM-disk, and then copies all the remaining folders recursively, file by file.
The chances are high :))
Not sure what hooks are these, could be for remote debugging - but you do not have 2 computers for this experiment, do you?
I have to admit I would never try to write 100GB at shutdown - I am pretty confident it will not succeed. Why do you need these 100GB written anyway ? If you are using the RAM-disk as a stash folder for Photoshop - it makes sense to save the final outcome on your HDD after you finish all intermediate retouching (which migh benefit from the RAM-disk speed) ....
An idea comes to me to write each file under a unique random name - and then rename it to the real name. Renaming is an atomic operation - so if the write is unsuccessful, the orginal file will stay untouched and there will be some bogus temp file with a random name alongside.
Perhaps adding messages to the EventLog may help? |
2 participants
Delphi 7 does not have a WidePosEx ?
AI/Gemini Pro 2.5 created it.
Plus it seems to have detected some bugs and fixed them.
Not sure if these are real bugs, could you check the changes ?
Also more advanced .gitignore added (For Delphi 12.3 and so forth) but you can ignore that if so desired.
Compiled/Build with Delphi 7 and working... just not sure if it's safe, AI mentioned something about -- in paths, not sure what it was about...
Only add to code if you believe it's good, I would just like your oppinion on it, not necessarily integrate it...