Jump to content

DarkFalc

Members
  • Posts

    8
  • Joined

  • Last visited

Everything posted by DarkFalc

  1. That 50GiB is actually a trimmed down version. It had got up to around 80GiB at one point before I realised how bad the VS installer is. Every month I run an update command to update the VS Layout (the offline installer files), however it turned out if you had version 1 of a package, when it updates and downloads version 2 of the package, version 1 is never used again but is also never deleted. I found a utility someone made which analysis the catalog.json file to find redundant packages and moves them all into a folder which you can delete, that cleaned out about 30GiB of unneeded files.
  2. I never actually burn it to any media, it's just mounted. As per my first thread, Microsoft hasn't offered an ISO since VS2015. Not having an ISO is extremely annoying for new developer machine build-up, or new build server creation. Microsoft either expects you to download the files every time, or... do something with the files if you make an offline layout directory. Running the installer over the network to a physical machine is way too slow, but copying the 50GiB folder of 12,000+ items over the network is extremely slow as well. If the installer was zipped up, you'd need to copy the zip over the network, ensure you provisioned enough space to have the zip and the extracted contents of the zip. However if it's an ISO, you can copy it over the network relatively fast (not being over 10,000 separate files seems to improves io), and you don't need to extract it, you can just mount it and run the installer. Similarly if a VM is being setup, you can just mount the ISO to the VM, instead of copying the files into the VM.
  3. Well.. according to Powershell, yes, and when I move the folder to the root of the partition Explorer shows that size as well, and thats the size ImgBurn said also. So yeah, I believe it is that size. It is a full offline layout installer of visual studio 2017, i.e. all components, so is pretty large. Part of my script creates a SHA512 hash of the iso, needless to say it takes some time haha.
  4. Yes I always have all those options enabled/disabled as well. I think it must be a path depth problem for windows, because once I moved the directory to the root of a partition it accurately calculated the size. I didn't think path depth has been a problem with windows since 16bit operating systems, where you'd have to abbreviate directories to be less than.. 8 characters from memory thisdirectoryistoolong would become thisdir~
  5. Hey Admin, thanks for the quick reply. I was doing as you requested when I noticed something screwy happening, not only did the file sizes to match, the file count was wrong as well. The thing is, obviously I had windows option view hidden files enabled, but still the count was wrong. So I tried doing a file count through Powershell and... what do you know... the Powershell size and count matches ImgBurn. I really didn't expect Windows to have a bug this bad. After noticing this and having a google I found quite a few other people raising issues with windows file size/count. Example. Sorry for wasting your time, thanks anyway.
  6. As per my previous thread I have automated iso creation for Visual Studio (Microsoft no longer offer an iso download). My script updates the VS layout directory, and then makes an iso of the directory. This seemed to be working fine for months until I realised that the iso being created is much much larger than it needs to be. I'm wondering if the block size or something similar in the iso is larger than my hard drive partition, causing the size on disk to larger (I am using FileSystem "ISO9660 + UDF"). The iso size seems to be this large as soon as the iso starts being built, its possible that ImgBurn is just over provisioning the size at the start. I have searched the forums before asking this question, I saw this thread which was a similar question but wasn't resolved. Below is the batch script I am running for creating the iso, the REM line is what a user can run (without REM) to execute the same command I am using without the variables. :CREATE_ISO ECHO Creating new VS2017 ISO ECHO %DATE% %TIME% >> "%LOGPATH%" ECHO CREATE_ISO Started >> "%LOGPATH%" "%IMGBURNPATH%" /MODE BUILD /BUILDOUTPUTMODE IMAGEFILE /SRC "%LAYOUTDIR%" /ROOTFOLDER YES /PRESERVEFULLPATHNAMES NO /RECURSESUBDIRECTORIES YES /INCLUDEHIDDENFILES YES /INCLUDESYSTEMFILES YES /VOLUMELABEL VS2017 /FILESYSTEM "ISO9660 + UDF" /DEST "%ISOPATH%" /START /CLOSE /NOIMAGEDETAILS REM IMGBURN.EXE /MODE BUILD /BUILDOUTPUTMODE IMAGEFILE /SRC "D:\TestInputDirectory" /ROOTFOLDER YES /PRESERVEFULLPATHNAMES NO /RECURSESUBDIRECTORIES YES /INCLUDEHIDDENFILES YES /INCLUDESYSTEMFILES YES /VOLUMELABEL VS2017 /FILESYSTEM "ISO9660 + UDF" /DEST "D:\TestOutputDirectory\test.iso" /START /CLOSE /NOIMAGEDETAILS ECHO %DATE% %TIME% >> "%LOGPATH%" ECHO CREATE_ISO Completed >> "%LOGPATH%" GOTO CREATE_CHECKSUM Before making this post I also tried changing the FileSystem modes and Folder/File restrictions but.. the output file always seems to be the same large size. Edit: I bought imgburn team a coffee since I have previously had support question answered.
  7. Thanks for the suggestion, genius. At first it looked like it almost was going to work but not quite. The errors were now in the log window rather than blocking error dialogue boxes.. but the build button was greyed out so I couldn't even build the ISO. But after changing to another I/O mode and also disabling all the read error options I could find.. it works! Legendary hacking powers admin (bows). Edit 0: I can't see how to mark or edit my original posts title to SOLVED, so I shall leave that to you LUK! Edit 1: Never mind I figured it out - you have to edit, then select "Use Full Editor"
  8. Is there anyway to suppress errors? I am automating the building of an ISO, I finally got the CLI command as I wanted for imgburn.. but... I can't run the command in a batch script unattended because imgburn hangs as it throws an IO error on launch. I have full admin access on my machine, EXCEPT - domain policy has disabled write to optical disk or USB. This isn't should be an issue as I only want to make an ISO, but imgburn throws errors at start up. These errors can be clicked past, but there doesn't seem to be a way to make my script function without hanging. I have looked for error suppression, but haven't found anything (only warnings). IMGBURN.EXE /MODE BUILD /BUILDOUTPUTMODE IMAGEFILE /SRC "D:\Junk\toDelete" /ROOTFOLDER YES /PRESERVEFULLPATHNAMES NO /RECURSESUBDIRECTORIES YES /INCLUDEHIDDENFILES YES /INCLUDESYSTEMFILES YES /VOLUMELABEL TEST /FILESYSTEM "ISO9660 + UDF" /DEST "D:\Junk\test.iso" /START /CLOSE /NOIMAGEDETAILS Is basically the command I am trying to execute in my batch script (names/paths changed), but it results in this (image attached). Is there a way to do this? Windows 10 Pro x64 ImgBurn 2.5.8.0
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.