Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ATR Image Explorer - Skipping FILE_0x.DAT files? #36

Open
dangithub42 opened this issue Jun 11, 2021 · 1 comment
Open

ATR Image Explorer - Skipping FILE_0x.DAT files? #36

dangithub42 opened this issue Jun 11, 2021 · 1 comment

Comments

@dangithub42
Copy link

I am questioning why I see only 3 FILE_0x.DAT files when there appear to be 5 deleted files from the Directory. Could there be a bug where every other FILE_0x.DAT file is not displayed?

I am using my APE to USB to make .ATR files/images of many real/physical diskettes using both a Happy 1050 and an indusGT drives. Later I look at some of the resulting .ATR files within the ATR Image Explorer (a great tool). On some images I see one or more .DAT files that always have names of the form: FILE_0x.DAT as in the 2nd picture. What are these? My guess is these were files that were 'deleted' therefore they are not found in the Directory (3rd picture) but their data sectors are still found/read by ProSystem. Is this the case? Note: ProSystem did not report any errors when it read this particular disk image '01a.ATR'

What are the 3 .DAT files circled in red?

Note 5 of the file names in the Directory are not listed above. Where these 5 files deleted? Maybe ATR Image Explorer has a bug in that it is not displaying FILE_02 or FILE_04?

@pvbestinfoo
Copy link

Hello
I've checked, this is not strictly a bug, but the current code in ATR image Explorer does not handle VTOC for 1040 sectors DOS 2.5 disk and correspondant file flags.
The FILE_xx.DAT are recovered DOS file, identified after checking actual links on sector disk. This files could have been either deleted by DOS (normal behavior), or either not identified by the app because of the handling limitation on 1040 sectors DOS 2.5 disk.
I will soon propose an official fork to correct this behavior : the results will be as follow:
Before - current version :
image
After- my futur fork:
image

A bientot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants