Oversize ISO Files

[DarkFalc]

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.

Edited June 4, 2019 by DarkFalc

[LIGHTNING UK!]

Post the log please.

Can you also add that folder via the actual gui interface, click the 'calculate' button and then post a screenshot of what it says on that tab.

[DarkFalc]

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.

 

[LIGHTNING UK!]

I’m pretty sure there’s another option you can enable that goes beyond just showing hidden files. It used to be known as ‘protected system files’ or similar. There could also be junction points or something... maybe that’s where the extra stuff is coming from?

[dbminter]

Yes, it's Hide protected operating system files (Recommended) under View under Folder Options.  I always disable it as part of a new PC install.

[DarkFalc]

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~

[dbminter]

Now, I have noticed random cases where when I imported a folder into a Build job in ImgBurn, it actually adds the contents from a folder from somewhere else.

 

Are there actually 48.9 GB worth of files in that VS2017_Professional folder?

[DarkFalc]

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.

[dbminter]

I've never used that software, but a near 50 GB installer seems like an awful lot.  That would be 1 DL BD or multiple DVD-9's.  And downloading that much content from an online installer seems like an awful lot, too.  Each time you'd want to reinstall the whole thing, you'd have to download 50 GB.  Which I can see why someone would want to save the files offline.  You may just need to devote a decently large flash drive to storing it.  The installation media doesn't need to be bootable, I'd guess.  Or use a BD DL.

[DarkFalc]

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.

[DarkFalc]

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.