Exploring "SETUP /P I;S=detectbus" and Grub4Dos: 8½ times Win98se on USB-drive

[deomsh]

@Wunderbar98 & @jaclaz

Thanks for contributing to my EXT2/3 question. My problem was far more simple, but I didn't make myself clear. I ment the EXT2/3 signature only. I found 0xEF53 in sector 3, in an article somewhere. It seems to also the main signature for EXT4, which is supported by Grub4Dos 0.4.6a (according to rmprepusb)

So I added finding this signature (\x53\xEF) in the source DEVICE to FATCOPY.G4B and everything is fine now. I found the EXFAT signature too, but still have to test this filesystem.

13 hours ago, jaclaz said:

About the ls "error message" post a sample of what doesn't work, maybe there is some of the in-memory tricks or "particular" varaibles that can be used.

BUT (random thought) in practice how big a problem (time/inconvenience) would be to copy on FAT target empty directories as well and then post-process the target removing (optionally) the empty ones?

Not the empty directories are bothering me, but to distinguish them from zero-byte files. Else ALL zero-byte files will become directories on the target. That's why I ruled them out, unless the /e switch is used.

If I use ls on an empty directory, ls highlights the empty directory "emptydir", but gives Error 15 if I try to open the directory. With cat --length=0 Error 2 in case of "emptydir" and, IF debug is on Filesize 0x0 is read out for "zerobyte.fil". Somehow I couldn't get rid of Error 2 (or Error 15 too with cat --length (fd0)/zerobyt/emptydir/ ), which was a big problem because copying is interrupted by a Grub4Dos error. My problem was I couldn't sent Grub4Dos error messages to NUL.

But today I found a way to identify a zero-byte file independent of an empty directory. Piping NOT redirecting to nul did the trick, finds filesize only if debug is on.

Now I can drop all special "empty directory"-lines in my batch file.

A small preview of (forthcoming) version 0.3 (I added a small file because an empty source directory is refused by FATCOPY.G4Bwas just a typo, "zerobyt" instead of "zerobyte").

Edited June 20, 2020 by deomsh
typo and corrections

[jaclaz]

Good , EXT2 and EXT3 are more or less the same, i.,e. EXT3 is EXT2+journaling, the link I posted was about the byte that signals that.

About not displaying error messages (in case of need) maybe you better use errorcheck off :

http://www.owl.homeip.net/manuals/systems/dos/grub4dos/files/commands.htm#errorcheck

see (example):
https://github.com/chenall/grub4dos/issues/168

jaclaz

 

 

 

 

[deomsh]

14 hours ago, jaclaz said:

EXT2 and EXT3 are more or less the same, i.,e. EXT3 is EXT2+journaling, the link I posted was about the byte that signals that.

I saw the EXT3 byte, but the link was still helpfull because I realized I had to search for a hex value to indentify EXT2 or EXT3 (or EXT4), than I found the signature very fast with google.

14 hours ago, jaclaz said:

About not displaying error messages (in case of need) maybe you better use errorcheck off :

http://www.owl.homeip.net/manuals/systems/dos/grub4dos/files/commands.htm#errorcheck

see (example):
https://github.com/chenall/grub4dos/issues/168

Thanks for remembering. In my batch-file errorckeck IS off, but during my endless testing on the command-line I didn't take notice of the errorcheck status. Since FATCOPY.G4B restores the original status of debug, errorcheck and pager I had to count for that. Stupid but true. 

The links are interesting. I am afraid I will have test again all supported filesytems separate, especially the different FAT-types. 

Edited June 21, 2020 by deomsh
Corrections

[deomsh]

About errorcheck, I found something strange.

It seems that during the run-time of a g4b-batchfile, errorcheck is switched on after a goto-statement.

I made a small test-batch:

---------------------------------------------------------
TESTERR.G4B
---------------------------------------------------------
!BAT
# Testing errorcheck status while running a g4b-batchfile
debug 1
errorcheck off
errorcheck status
goto :end
:end
errorcheck status

---------------------------------------------------------

The result: see the picture.

Is this normal behaviour?

I am using Grub4Dos v0.4.6a 2019-09-09.

[jaclaz]

No idea, if it works that way, it works that way. 

Does it the same on call ?

I mean, it does make some sense (even if it is unexpected) a goto is usually a branch and errorcheck may be reset to its default value (on) on a branch, a call/goto :eof should instead  keep the same settings.  

jaclaz

[deomsh]

12 hours ago, jaclaz said:

I mean, it does make some sense (even if it is unexpected) a goto is usually a branch and errorcheck may be reset to its default value (on) on a branch, a call/goto :eof should instead  keep the same settings.  

I tested call/goto :eof with following batch-file

------------------------------------------------
GOTOERR.G4B
------------------------------------------------
!BAT
# Testing errorcheck status with call&goto :eof
debug 1
errorcheck off
errorcheck status
call :checkerr
errorcheck status
errorcheck off
errorcheck status
goto :end
#----------------------------
# Sub-routine checkerr
#----------------------------
:checkerr
errorcheck status
goto :eof
#----------------------------
# End of sub-routine checkerr
#----------------------------
:end
errorcheck status 

------------------------------------------------

Same results, after each goto-statement errorcheck is switched on (with version grub4dos-0.4.6a-2020-01-12 too)

But it could to be related to issue #102: https://github.com/chenall/grub4dos/issues/102

With a Grub4Dos version before this issue was raised, GOTOERR.G4B gives this result:

And after the issue (something is mentioned in the bug file of following version):

The bug *thing* I found is here, but I can't interpret it: https://github.com/chenall/grub4dos/commit/b90a412f5fb78aa23d12c3fb9b0eb74c4751fbfb

Also I am not sure if it is directly related to issue #102.

[jaclaz]

Yep, you should contact Steve about this and possibly find with him a possible solution before requesting a bugfix.

Basically what I believe happened is that Steve found a bug in a function that shouldn't IMHO even exist (goto in menues [1]) and yaya initially (correctly) suggested to explicitly set errorcheck on, but later, upon the insistence over this (non-) issue "fixed" it, unfortunately (evidently) fixing it "systemwide".

I presume that the only sensible way out would be to revert the change (having goto work normally in batches) and adding a new command mgoto or gotom or gototitle to be used in menues.

But doing something like that will make any number of existing menu.lst by Steve6375[2] "incompatible".

As said changing a systemwide setting on a goto (making a different branch) might have some justifications, whilst changing it on a call on the goto :eof (please read as "return") is IMHO seriously "wrong".

Since (I believe) grub4dos can understand if it is running a menu or a batch, maybe the only possible way out would be *something* that automatically turns on errorcheck to on in goto's ONLY in menues BUT leaves it untouched in batches, no idea if this is possible.

jaclaz

[1] generally speaking myself and Steve have opposite views about the structure of grub4dos external files, I prefer to have extremely simple menues and (simple or complex) external scripts/batches, while he tries to cram each and every possible options in the menues, there is nothing inherently bad in either approach (though of course my personal opinion is that my approach is better ) and both have their advantages

[2] Steve is most probably the most prolific "western"  developer of grub4dos related thingies and the unofficial (but official for me) communication officer with the good guys that develop grub4dos (chenall and nowadays yaya) so it is IMHO better (even if not strictly *needed*) to talk with him about the issue and possible solutions beforehand.

Edited June 25, 2020 by jaclaz

[deomsh]

Thanks for the explanation, i will contact Steve.

In the meantime I tested GOTOERR.G4B on four machines, no differences (two real chipsets and the two VBOX-chipsets).

Also the Grub4Dos-version just before 20160315 has the "old" behavior.

For the time being an easy solution is to insert an errorcheck off line if needed.

On the sunny side: FATCOPY.G4B is (almost?) "errorcheck-on-proof", and I have had unlimited opportunities to find out tricks to live with this problem.

[deomsh]

On 6/26/2020 at 11:17 PM, deomsh said:

Thanks for the explanation, i will contact Steve.

Steve said me to raise an Issue, I did in July, but still no comments.

I ran into another strange issue while testing FATCOPY.G4B version 0.3

All copying is good, except Windows' LNK-files, gives "FAT Error:   (1) A hard error occured in the low level disk I/O layer".

I tried to read LNK-files with cat --hex /FILE with many versions of Grub4Dos. Only grub4dos-0.4.5b-2012-01-16 behaves as expected, all other version tested NOT:
grub4dos-0.4.5c-2014-01-17
grub4dos-0.4.5c-2016-02-26
grub4dos-0.4.6a-2017-08-30
grub4dos-0.4.6a-2017-12-05
grub4dos-0.4.6a-2019-05-12
grub4dos-0.4.6a-2020-01-12

Since FAT 15/02/2015 didn't work with Grub4Dos 0.4.5, I can't downgrade my project!

Some screenshots of my (dutch) Windows Verkenner.lnk (=Windows Explorer.lnk)

All LNK-files tested gives some sort of weird behavior, some I took from my Windows 10 installation too.

 

[jaclaz]

The source is on NTFS?

Try on those .lnk files the blocklist command.

There is (was) an issue with resident data in $MFT entries that should have been resolved, but maybe it was accidentally re-introduced, or maybe .lnk files have some special attribute.

But you have a backslash in some of those commands, is that an escape for the space in the name?

Does it happen no matter if there is a space in the name of the .lnk?

Try with an explicit path AND use [TAB] autocompletion to read the file, example:

cat --hex (hd0,0)/lnkfiles/w[TAB]

Try with a .lnk file with no spaces in the name.

Or maybe - for some reasons - the header of the file is automagically (please read as "stupidly") recognized as *something* I seem to remember vaguely that there was an issue with some files that were recognized (did I say stupidly?) as being gzipped files (.gz) and attempted to decompress on-the-fly.

Try changing the first 4 bytes of the file to (say) 20 20 20 20 and see if the behaviour is the same.

If you prefer the issue could logically be connected to:
1) "nature" of the file on the filesystem
2) name/path of file
3) contents (header) of file

jaclaz

 

[jaclaz]

14 hours ago, deomsh said:

Steve said me to raise an Issue, I did in July, but still no comments.

Add there a link to the relevant posts on this thread, and/or some details, no offence intended  , but if I was a grub4dos developer, reading your two lines I would think "Here comes another loonie that has not undestood the #102 issue that is solved."

Mind you I like it when communication is simple, streamlined efficient and not verbose, but maybe you could have been a taf bit more descriptive.

jaclaz

Edited August 23, 2020 by jaclaz

[Wunderbar98]

Hi Deomsh. May be a grub regression or simply intended kludge removal. As @jaclaz indicated full pathway and tab autocomplete is best. Avoid spaces, Unix-based commands are case sensitive and double-quotes should wrap the entire pathway not just a spaced file name. Try like below and if it doesn't work then full pathway.

cat --hex "/LNKFILES/Windows Verkenner.lnk"

[deomsh]

On 8/23/2020 at 11:15 AM, jaclaz said:

Add there a link to the relevant posts on this thread, and/or some details, no offence intended  , but if I was a grub4dos developer, reading your two lines I would think "Here comes another loonie that has not undestood the #102 issue that is solved."

Mind you I like it when communication is simple, streamlined efficient and not verbose, but maybe you could have been a taf bit more descriptive.

Thanks, point taken. I will make a new attempt.

On 8/23/2020 at 10:57 AM, jaclaz said:

The source is on NTFS?

Try on those .lnk files the blocklist command.

I tested on FAT and FAT32 so far, but NTFS gives the same results. Can you tell something more about the blocklist command please?

On 8/23/2020 at 10:57 AM, jaclaz said:

But you have a backslash in some of those commands, is that an escape for the space in the name?

Does it happen no matter if there is a space in the name of the .lnk?

Try with an explicit path AND use [TAB] autocompletion to read the file, example:

cat --hex (hd0,0)/lnkfiles/w[TAB]

Try with a .lnk file with no spaces in the name.

The backslash is always provided by ls before a space, in my experience.

I did some new test on NTFS, without spaces in Path/File and using TAB-autocompletion. I used two renamed IrfanView-lnk files, one from Windows 98SE, one from Windows 10 64-bit. Same strange output with cat --hex with different length´s. No difference.

If I change first four bytes as you suggested, other bytes are looking fully normal now.

For comparison I added the same amount of Lister´s HEX-views of the original files.

On 8/23/2020 at 11:51 AM, Wunderbar98 said:

Hi Deomsh. May be a grub regression or simply intended kludge removal. As @jaclaz indicated full pathway and tab autocomplete is best. Avoid spaces, Unix-based commands are case sensitive and double-quotes should wrap the entire pathway not just a spaced file name. Try like below and if it doesn't work then full pathway.

cat --hex "/LNKFILES/Windows Verkenner.lnk"

@Wunderbar98 thanks for your comment. In Grub4Dos qoutes are taken, but starting only AFTER the first backslash. Combined PATH/FILE between qoutes is still a usefull hint, because I am working on a LFN-module to copy LFN´s in /PATH1/FILE1 to SFN´s in /PATH2/FILE2.

I have made you nice picture of the possibilities. By the way, I found "read" case-sensitivity only on Linux file-systems I have tested. Further I have red that UDF should be case-sensitive too.

Edited August 24, 2020 by deomsh
Typo

[jaclaz]

Ok,

The blocklist command tells you where exactly (on which extent(s)) a file resides on the volume.

The (hd2,0)284918+3 is ok.

The file is non-resident (on NTFS), is contiguous and it takes three sectors.

The (hd2,0)6412[296-682] is the peculiar case of a resident in the $MFT file, and it makes sense since later you have it as (fd0)1262+1, i.e. it occupies only one sector (for max sizes of $MFT resident files on 512 bytes and 4KB sectored devices, please read as record 1KB and 4KB), see:

 https://www.forensicfocus.com/forums/general/mft-resident-data/

Earlier version of grub4dos had issues with these (hence the "default" file was made 2KB)

But evidently that is not the problem.

The problem must lie in something similar (or connected) to the gzip issue (but the gzip header is completely different 1F 8B)

 The 4C (or more likely the 4C 00 or the 4C 00 00 00 or the 4C 00 00 00 01 14 02 00) must be triggering *something*.

What happens if you cat --hex the blocklist? (no idea if it changes something )

I.e. try 

blocklist /lnkfiles/irfanW10.lnk

(hd2,0)284918+3

cat --hex --length=16 (hd2,0)284918+1

jaclaz

 

 

Edited August 25, 2020 by jaclaz

[deomsh]

@jaclaz

Thanks for the clarification of the blocklist command. I tried cat --hex --length=16 (hd2,0)284918+1 but no difference. See picture below, lines 2 and 3.

In a file with the header of 4 bytes there was no problem reading with cat --hex. The next 16 bytes are the GUID according to https://github.com/libyal/liblnk/blob/master/documentation/Windows Shortcut File (LNK) format.asciidoc Here lies the problem, when I wrote the first 20 bytes to a 20 byte file with write : same problem as before. But when I tried this a second time to make a printscreen, I got Error 71 Attempt to write a gzip file. See picture below.

The raw command seems to solve all problems, even with dd - I never used raw before. See second picture. First 3 lines to produce the file 20bytes.lnk, with header+GUID form a Windows Shortcut File. The later lines are for the dd-test, without and with raw.

So you seems to be right that there is a connection with Grub4Dos treatment of gzip.

Edited August 25, 2020 by deomsh
Typo