[Android Software Development] anagramgenius:
Hey [MENTION=4544860]osm0sis[/MENTION], I have a similar issue mentioned in this post by [MENTION=7350669]wzsx150[/MENTION]. I get "Access is denied." error when unpacking the ramdisk to "ramdisk" folder. v3.5 does require administrator privileges for unpacking ramdisk to the "ramdisk" folder and also to delete that folder. I used both v3.4 and v3.5 to unpack same boot image. While unpacking, v3.5 seems to have some problem copying the contents of ramdisk to the folder. Also when cleanup.bat is used without administrator privileges, it doesn't delete the "ramdisk" folder. I have to manually delete it while giving the administrator privileges.

Here's the log of v3.5

Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers

Supplied image: boot.img

Setting up work folders . . .

Image type: AOSP

Signature with "AVB" type detected.

Splitting image to "split_img/" . . .

BOARD_KERNEL_CMDLINE console=ttyMSM0,115200,n8 androidboot.console=ttyMSM0 earlycon=msm_serial_dm,0xc170000 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 sched_enable_hmp=1 sched_enable_power_aware=1 service_locator.enable=1 swiotlb=1 firmware_class.path=/vendor/firmware_mnt/image loop.max_part=7 buildvariant=user
BOARD_KERNEL_BASE 00000000
BOARD_NAME
BOARD_PAGE_SIZE 4096
BOARD_HASH_TYPE sha1
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_SECOND_OFFSET 00f00000
BOARD_TAGS_OFFSET 00000100
BOARD_OS_VERSION 9.0.0
BOARD_OS_PATCH_LEVEL 2019-05
BOARD_HEADER_VERSION 0

Unpacking ramdisk to "ramdisk/" . . .

Access is denied.
Error!

Press any key to continue . . .

And the same boot image is unpacked with v3.4. It doesn't have any problem unpacking the ramdisk to the folder. Also there's no problem when cleanup.bat is used. It deletes the "ramdisk" folder normally. Here's the v3.4 log without any error.

Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers

Supplied image: boot.img

Setting up work folders . . .

Image type: AOSP

Signature with "AVB" type detected.

Splitting image to "split_img/" . . .

BOARD_KERNEL_CMDLINE console=ttyMSM0,115200,n8 androidboot.console=ttyMSM0 earlycon=msm_serial_dm,0xc170000 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 sched_enable_hmp=1 sched_enable_power_aware=1 service_locator.enable=1 swiotlb=1 firmware_class.path=/vendor/firmware_mnt/image loop.max_part=7 buildvariant=user
BOARD_KERNEL_BASE 00000000
BOARD_NAME
BOARD_PAGE_SIZE 4096
BOARD_HASH_TYPE sha1
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_SECOND_OFFSET 00f00000
BOARD_TAGS_OFFSET 00000100
BOARD_OS_VERSION 9.0.0
BOARD_OS_PATCH_LEVEL 2019-05
BOARD_HEADER_VERSION 0

Unpacking ramdisk to "ramdisk/" . . .

Compression used: gzip
9568 blocks

Done!

Press any key to continue . . .

v3.5 works normally like v3.4 if I keep the Android Image Kitchen inside C drive in any folder where my windows is installed and also when I run unpackimg.bat and cleanup.bat as administrator. I checked the permissions of the "ramdisk" folder in both v3.4 and v3.5. When I click on security tab of "ramdisk" folder in v3.4 I get the usual Windows Security warning "The permissions on ramdisk are incorrectly ordered, which may cause some entries to be ineffective." But in v3.5, I don't get any warning for that folder and only two permissions are listed under the 'Groups or user names:" header namely "SYSTEM" and "Administrators".

When I tried to unpack boot images in a USB flash drivewith FAT32 file system, it unpacks without any problem. So I thought it must be because of the weird folder permissions you mentioned here. I also formatted my USB flash drive to NTFS. But it could unpack successfully. Then I thought the problem is with my internal and external hard drives. So I checked it with another PC with newly installed Windows 10 and also the partitions were new. Same issue with the v3.5.