I finished a generalized version to get/ set (most) attributes on FAT12, FAT16 and FAT32. Including making and deleting Long File Names, in the broadest attribute-sense. The script is written as a Loosely Linked Library, in Wonko's way (I hope), and named: ATTRIBFT.LLL. I included a simple command-line utility too: ATTRIBFT.G4B.
https://github.com/deomsh/ATTRIBFT.LLL
There are about 30 primary and 15 derived function exported, no other external programs are used, just internal Grub4Dos functions. On each function there is 'help' available, including one or more examples.
See next three print screens for whats going on:
Apart from the 'normal' attributes all dates and times can be get/ set. I call normal MS-DOS date and time 'moddate' and 'modtime': means date/ time of last modification, but not in their function-name for simplicity. Date of last access is 'accdate' and date and time of creation on disk 'creadate' and 'creatime'. Last three are normally NOT set by MS-DOS, as far as I know.
A few examples using functions from the third print-screen above. Be aware I use further the command-line front-end ATTRIBFT.G4B (G4B is a known command-extension set by my MENU.LST):
BTW the last used function in the print-screen before is showed to introduce an instance the 'result-variable' contains so-called 'set-variables'. Also can be seen set date is protected (set time too).
For curiosity I included read-out of the byte used by Windows-NT to give case-information of the name-part and the extension-part of a 8+3 file-name. Also the value of the pointer to Extended Attribute (if non-zero. These EA's can not exist on FAT32).
The main part however is related to Long File Names, which was very heavy to get them 'near' with a Grub4Dos-script. The get-functions will not write anything to disk, but 'makelfn' and 'dellfn' will do.
See next print-screens for some examples, but keep in mind corresponding 8+3 file/ directory names must exist already on disk. I use grubutil 'FAT' for this purpose.
BTW I tried to protect every 'write to disk' heavily, Grub4dos has no internal protection. Although I even hard-coded in the script not to write below 0x200, there are always other risks than just overwriting your Partition Boot Record. So if you would like to try set/ make/ del-functions: better not on your main FAT-OS, but best on an image, or even mapped to memory, or in a virtualised environment (I used Virtual Box and Qemu for Android). Always back-up first!
I am highly indebted to Wonko the Sane, as can be seen 'higher' in this thread. I used his version for sub-routine ':checksumSFN' and a simplified version of his ideas for the 'help-system', as can be seen in the print-screens above.
A small note about my structure of loosely linked library: I started with 'goto :%~1' instead of calling. So addressed label is starting point of a function and has full access to all command-line arguments, including %0, and can have their own goto :eof and own return-values.
ATTRIBFT.LLL is using two return values: 1) the variable 'result' OR the variable 'message', containing some text if there is no result. 2) Always the variable 'output', containing set variables like filesystem and (partial) read-out of the Partition Boot Record.
A few notes about scripting:
One of my test VHD's was 40GB (FAT32 of course) and filled with about 17GB of files. Searching with 'cat' and using '%?%' to get the offset on disk seems to be limited to 32-bits values. So I had to use lines like these:
raw cat --skip=%bytedone% --locate="%ENTRY%" --length=%dirlen% --number=1 %device%%0+%devsect% | set entry= &; if exist entry && set /A entry=0x%entry%
Maybe the part '&; if exist entry &&' is not needed, I am just used to it.
This gives a serious limitation, only '--number=1' can be used. In case of finding a directory-entry like in the line above, the first entry is searched only, so no problem. However when I had to search for contiguous deleted directory-entries (E5 on first byte), 'things' became more difficult. Although luckily clusters start always on a sector-border, so E5-not-on-first-byte can be sorted out by calc and set a higher offset for next search-loop, calc is limited to 0x7FFFFFFF regarding dividing operations. So from 2GB on I had to insert in my lines scripting like:
'calc 0x%skipbyte:~-2,2% % 0x20 &; set /A skipbyte=%skipbyte%-%@retval%+0x20 &; ....
So only last two bytes are evaluated by calc (be aware directory-entries are always 32 byte-units, so there is a remainer only if the evaluated value is not a multiple of 0x20 = 32)