Imaging from empty image directory destroys target OS
-
[B]Fog doesn’t check to ensure an image exists in source directory before wiping target computer.[/B] So long as the directory for the image is present, Fog assumes an image is present and proceeds to wipe any computers tasked to install said image before finally failing because it can’t find the image.
A check needs to be done to ensure an image exists in said directory prior to starting the imaging process. The mere presence of a directory isn’t enough.
Fortunately, I found this out while testing so it didn’t cause any damage.
PS: Is this the correct place to submit bug reports or is there a bug tracker somewhere?
Thanks
-
fog only creates a directory upon the successful creation of an image to match it. if fog is working correctly, the only way a directory exists without a proper image is if someone is manually changing things on the server.
if fog is creating directories without first successfully creating images, then that is a bug that we would like reported. if you are wanting fog to check on changes made by users manually changing things around on the server, that’s a feature request. -
To further add to this, fog used to do the same things you’re saying without even caring if the directory was present. This little change is already a feature added. Fog is not creating directories of zero files so my guess is somebody created the directory first.
-
You’re both correct. Fog isn’t creating empty directories. I created the empty directory by hand while I was troubleshooting an issue. This was an error on my part plain and simple. However, it’s not uncommon for admins to move things around outside of the Fog admin interface.
I suggest adding a feature to check for the existence of the image prior to imaging.
-
The only problem I see with “checking” for the files is we don’t know what files are supposed to be present in the first place. In the case of Windows Resizable we expect at the least sys.img.000, but in the case of multipart images, there is no specific thing.
-
I’m not sure what’s going on behind the scenes so take this with a grain of salt. What do you expect to see after the HD has been formatted? (I don’t think you’re formatting but whatever it is that nukes the OS). The script try’s to copy “something” and ultimately can’t find it. A check could be done prior to the formatting stage to make sure that something exists.
-
I understand what you’re saying. What I’m telling you is, while this check could be done to verify files for Windows Resizable images, all the others are copied in a format of d{disknum}p{partitionnumber}.img
I can add a check for the sys.img.000 file, but there’s no common standard that states every disk is always going to be d1p1,d1p2.
Also, how far do we take this? We’re not storing the file names anywhere right now. So if somebody comes in after we’ve created the image and deletes, randomly, some files from the directory, you would be in exactly the same state.
