- Keyfile not required anymore.

Excellent news for the MorphOS community, And I don't regret paying for a moment.

Great news! I bought IceFS soon after it's release and i am using
it with all my partitions (except boot partition) and it works great.
THX Leif!

Thanks a lot Leif too !!!

Now, think to buy a licence for IceDoctor

I copied 100GB from an SFS disk to a bigger IceFS disk. After about 80GB a requester popped up and told me "NewDisk:bla/ is a directory". Sure, this is why I started copying all the files to this drawer 'bla' so this message has no meaning because it was already clear to the user (me). Otherwise I could not put the files and drawers there inside. So what is it about this requester? After pressing 'OK' button it continued to copy files and fineshed but now I don't know if anything got lost or not copied.

great news! :)

Quote:

Interesting. Any more information what program put up this requester ? Should be either Ambient or C:Copy.
You can use
Rival1.2b to compare the source and destination directory.

Double post.

[ Edited by Leif On 2011/11/19 10:50 ]

Quote:
I formatted a fresh harddrive with IceFS 2.8, no files on it before. Created an empty drawer and pulled all files via drag and drop from one drive (SFS) to another (IceFS). So it was Ambient's requester. Comparing all directories with Rival isn't very comfortable. I thought of running an MD5SUM on both the old partition and the new drawer but I d o not know if this will give the same in general for a) a partition and b) a drawer.

Quote:

Not sure how it could get any more comfortable
than using Rival really. What's the problem with it ?

Now is this filesystem a good replacement for the current standard filesystem on MorphOS (sfs?) and can it handle files over 4gb ? As in dvdimages or as such ?

> can it handle files over 4gb ?

From the link in the news item:

"64bit file/partition/extent sizes (actually very close to 2^63 bytes)"

Quote:

It is uncomfortable to scroll through such a long list of files to compare. Rival sometimes displays differences in files from left to right although they are identical so you always have to check twice. This takes more time than is needed. The other problem is that Rival eats up all the RAM for scanning both devices to compare. I am left with 2 out of 512MB now and Rival is still not showing any output. So Rival is of no use for large drives or many files as you run out of memory before it can tell aou anything about your files.

IceFS also seems to have problems with reading files from another IceFS drive. I bought two new drives (man, they became expensive!) and copied files from one ICeFS to the other ICEFS. Every few files the copy process (DND from Ambient) stalls. The progress window stops and IceFS creates an empty file. Stopping the process lets the Ambient lister in a meditating status. Ambient is totally blocked everytime. I have to reboot the machine, delete the empty file and copy it again.then it works for some more files until it stalls again. Do this a couple of times and you get This does not happen when copying from SFS parttion.

[ Edited by connor On 2011/11/20 18:29 ]

Quote:

OK. Good points.

Quote:

Quote:

OK. Would be fine to see these two bugs vanish.

Quote:

Sorry. False alarm on the bug finding.
So we are back to I have absolutely no clue as to what
might be the problem. I dont have mac mini to try on
either, but I know there are IceFS users on Mini so,
if someone else have same problems I'm gonna hear
about it.

Quote:
Why do you need a Mac mini for that? I am using a Pegasos either. I am sure any PowerMac, eMac, Efika ... will also help you.

Quote:
I must say that this ALSO happens when copying from a SFS partition. It just did not appear at first glance but now I have several cases where the same happens. Maybe it's not about reading but about writing, so it happens from no matter which source filesystem.

[ Edited by connor On 2011/11/21 12:29 ]

It looks like a problem in your "max transfer" settings in HDConfig. You may have to check/fix the values for your failing partitions.

Quote:
It is 0x7fffffff

Quote:

Yeah. Might be worth a try. Use 0x20000.
If that does'nt work change Mask to 0x7ffffffc.

@connor:
Could you do following so I can get more information:
1. Type "IceCheck your_ice_partition QUICK" in shell.
2. Start IceConfig, select the ice partition and select in the
menu: settings/type config.
Then paste both outputs here.

Quote:
this should really be up to the developer and not the user. No user should ever have to fiddle with these settings.

Quote:

1.
Ram Disk:> IceCheck dh1: quick
IceCheck (05.11.2011) by Leif Salomonsson
Partition device "sata.device", unit 0
Partition # sectors $E8E06540, start sector $2370
Partition blocksize 2048, reserved blocks 2, prealloc 0

*** basic check of filesystem ***
Totalsize (not including reserved blocks): $1D1C0CA7000 (1863 GiB + 12 MiB + 668 KiB)
Formatted with version: 2.7
Blocksize: 2048
Formatted date: 18.11.11 [19:08:06]
Hashtype: 2
Extinfo: $400 SOE: $20000 EOE: $1D1C0CA6800
Rootentry: $20140, rootnode: $201C0 roothashtab: $20240
Journal: $10000
Name of volume: "Data"
Valid roothashtab backup detected.
Valid filesys backup detected.
Recyclednode: 132800
Number of reycled files: 16
Number of recycled bytes: 4533383168
Logfile: 134080
FS Logfile size: 67108864. used: 56569529
Comment:
Basic check done with 0 errors.
Ram Disk:>

2.
Config for DH1:
Cacheline size: 32768 bytes
Max Cachelines: 64
Max Meta cache size: 16384 bytes
Prealloc factor: 128
Inactive timeout: 2 tens of second
Active timeout: 50 tens of second
Max recycle files: 16
Max recycle bytes: 0
Default file E-bit: 0
File change log: -1
IO align mode: 0
Cacheline release: 8 seconds
Debug flags: $0


Strange to see that the drive got formatted with IceFS 2.7 although I removed 2.7 on this drive, saved, installed 2.8 to the rootblock, formatted newly with FSFormat and this shows 2.8.

Quote:

True. Problem is, filesystem can now know about these
limitations in the device drivers (or hardware), there is no API to query this. Good new is, few drivers have these limitations anymore, so can usually be ignored anyway. But I'm not 100% sure all drivers are free from these limitations yet.

Quote:

Maybe you didn't reboot in between ?
Anyway, if it says 2.7 then 2.7 is what was used to format.

Now.. output didn't reveal much interesting info.. will have to think a bit what to do next..

Quote:
I rebooted more than 100 times inbetween and switched oof for about 10 times. If it was 2.7 for format then why do all other tools say 2.8? I installed 2.8 in the RDB of this drive, rebooted and started FSFormat which told me 2.8. Why does it take 2.7? There is 2.8 in the RDB of this drive. There is 2.8 in L: . There was 2.7 on another drive which I used at first. From there I want to copy files to the 2.8 drive. This drive was plugged in at the same time. So all that can be is that FSFormat ignored the drives own RDB, ignored L:icefilesystem and ignored what it told itself but picked the only appearance of another drive, of the only drive that has a lower version of IceFS in its RDB but still said "I install 2.8 now". Quite strange.

Quote:

FSFormat never tells you anything about any kind of version of
the filesystem. IceConfig tells you what version is currently *running* on the partition. IceCheck tells you what version *formatted* the partition. When you use FSFormat (or Ambients Format) the *running* version of the filesystem is used for this.
This is how it works on Amiga/MorphOS.. the *running* version
of the filesystem is told to do the formatting of the partition, creating a volume.

Quote:

You are right. I mixed up which tool displays the version info because I ran all tools before formatting to be safe that 2.8 will be used and all who displayed anything displayed 2.8. This was at least IceConfig then.
So 2.8 was the running version. How come it takes another than the running version, another than the version that is installed in the RDB of the very same drive that is going to be formatted? Any idea?
I already copied a lot of data to this drive which took a long time. I do not awnt to do this again. Will I have any disadvantages from the current state: installed with 2.8 and 2.8 in RDB?

[ Edited by connor On 2011/11/21 19:24 ]

Quote:

No disadvantages.

Also your mirrorcopy (shell prog) stops at copying. Whenever it stops it is somewhere inbetween and it leaves the current file as partly written file. No requester, no message comes up that copy process has some problems. It just stalls at any point and blocks Ambient with a waiting pointer.

@connor:

I am able to reproduce your problem with a wrong (too big) maxtranfer value (with SFS, PFS3 and ICEfs). Did you try to change it?

[ Edited by Jeckel On 2011/11/25 10:12 ]

[ Edited by Jeckel On 2011/11/25 10:12 ]

Quote:
Setting max transfer to 0x20000 crashes HDConfig as soon as I click on the red SAVE button. It crashes both from hard drive and from CD booted. After a reset, the old value 0x7fffffff is back again. Just after severl tries it got saved. Not very reliable this HDConfig. Or it is because of IceFS. I cannot guess. Just with SFS it never had these problems.

What does this value mean at all? Number of bytes that can be copied at once? So you say "let it just transfer 20,000 bytes at once"? Or is it something else?

Anyway, if the default value is wrong and you all know about it then why is it the default value? And why is there no word about it in the readme to set it to another value? To force fails? And why does it work with SFS if it is so wrong?



Next bug: after copied around 840GB a requester pops up
Meta error: Sum check failed when reading meta @ B6F689B7C0 [tag 6] (a.v.: adr $B6F689B7C0 tag 6 size 128)
Retry or Cancel

Now whenever I open up this partition the same requester pops up again and I can not see any files in Ambient. It also pops up when I go to from Shell. If I say "dir" in Shell it tells me "Could not get information for //here the line ends, so for what can't it get information?
Error 1000". So all files that I copied to this drive are no more accessable. I ran IceCheck. It checks for hours but does not repair anything that lets me access my files again.

> What does this value mean at all? Number of bytes that can be copied at
> once? So you say "let it just transfer 20,000 bytes at once"?

Yes. You can read more about that there:

http://hjohn.home.xs4all.nl/SFS/maxtrans.htm

Quote:

Sounds pretty insane. Something is broken, hardware possibly.

Quote:

Yeah, but it is in hexa decimal, so it means 131072 bytes :)

Quote:

Nobody had to change this value yet _afaik_.
But it seems it did make a difference atleast.

Quote:

Thats sucks. Yes IceCheck does not repair, it just checks.
And it is slow. IceDoctor is faster, but needs a key if you want it to actually repair.
Something is wrong, hardware wise most likely. IceFS
detects small meta errors quickly unlike SFS. Maybe I
should add third option: "continue with errors" to emulate
SFS behaviour.

Quote:
So in other words: From IceFS' view sata.device is badly written. Strange that it isn't from SFS' view.

Quote:
Hardware works pretty perfect with any other filesystem and operating system.

Quote:
Then why does Jeckel assume that there is a problem with "my" settings when those are the original ones?

Quote:
Hardware is working perfectly. Just when I use IceFS errors occur.
What would "continue with errors" mean? That files do not get copied? That corrupt files get created although the original is intact?

Here is the output of IceCheck:

Ram Disk:> IceCheck Data:
IceCheck (05.11.2011) by Leif Salomonsson
Partition device "sata.device", unit 0
Partition # sectors $E8E06540, start sector $2370
Partition blocksize 2048, reserved blocks 2, prealloc 0

*** basic check of filesystem ***
Totalsize (not including reserved blocks): $1D1C0CA7000 (1863 GiB + 12 MiB + 668 KiB)
Formatted with version: 2.7
Blocksize: 2048
Formatted date: 18.11.11 [19:08:06]
Hashtype: 2
Extinfo: $400 SOE: $20000 EOE: $1D1C0CA6800
Rootentry: $20140, rootnode: $201C0 roothashtab: $20240
Journal: $10000
Name of volume: "Data"
Valid roothashtab backup detected.
Valid filesys backup detected.
Recyclednode: 132800
Number of reycled files: 16
Number of recycled bytes: 5110563914
Logfile: 134080
FS Logfile size: 67108864. used: 35162743
Comment:
Basic check done with 0 errors.

*** checking main extent linkage ***
.......................................
2773912 total extents (5 free 7853 pool 2766054 data)

*** checking free extent linkage ***
total space available: $FE5396A000 bytes (in 5 extents)

*** checking reusepools extent linkage ***
extent $632C09C000 bitmap $632C09C040 allocated blocks: 1007/1021
extent $B808AFD000 bitmap $B808AFD040 allocated blocks: 745/1021
2 total extents

*** scanning file system objects, file data and directory structure ***
.........................................................read meta "entry" @ $B6F689B7C0 failed sum check
error: problem scanning entries
failure was in directory "<root>", filename "ST99GB1SFS"
188161 directories, 2443611 files, 0 softlinks and 0 hardlinks scanned
Ram Disk:>


I just removed those hundreds of dots '.'. So it says it found a failure and does not say what kind of failure and how it got to it by only copying files from an existing harddrive there. I did not open any file on this drive itself to change it. I just deleted files that did not get copied completely because otherwise mirrorcopy stumbled over them.

@connor:

If HDConfig crashes this way I'm afraid you actually have a big system and/or hardware issue on your computer.

Quote:
Don't be afraid because this is wrong.

I gave the drive to a colleague who has IceDoctor. We ran it and it took over night. Then on clicking "Browse volume" no file was listed. So everything seemed to be fine? The log said "run update disk then to perfrom reparairings" (or similar). We did that but it said "RAm Disk is full". Yes, because Browse volume ate up all mememory! There were only 182KB left. We searched for t:DH1.metabackup and wanted to see if this was the big file but it was still empty. It was just prepared but nothing had been written to it. So all the memory was eaten up outside of files but inside IceDoctors structures. So update disk was impossible because we could not free the memory occupied by Icedoctor (occupied for nothing as the list of "Browese volume" was empty). Then we had a look at "List modifications" and after a long list of things like "Entry @ $45F... size 128 "allfilenamesarecut" (no filename had his original length) it suddenly stopped and the app was meditating. So all this run was in vain. After killing IceDoctor, no additional byte of memory was freed again. So there is still a lot of work to do on IceFS and IceDoctor.

We started a new scan now. Hopefully it will be done in the evening.

BTW: what is the difference in IceDoctor between Errors: Ignore and Errors: No auto retry? You could tell that in the readme.


GRRR! THere is a bug with cliboard and OWB. I sent this text from colleague to my mail address. I copied the text into clipboard with YAM and pasted it to OWB's text field but only the last paragraph gets pasted. When I paste to "ed" or any other program all the text gets pasted. Just not in OWB. I have to copy every paragraph singly.

The scan is over and this time directly using "Update disk" and a reboot afterwards let us access the files again. But now it prduced more than 50 drawers like ".orphaned_F6723bla" although we did NOT set the checkmark "recover lost extents". From the readme those files only appear when you hit that checkmark. How come they were produced, anyway? From first sight it did not touch the "real" directories and files, at least.

Quote:

No, thats not fine at all. Probably not enough memory.

Quote:

You ran out of memory. Ill look into improving memory usage. Right now,
an internal tree is kept buffered after you close browser view.. it is ment
to speed up things next time you use browse, but in low memory
situations not great perhaps..

Quote:

Ignore: dont check for errors at all.
No auto retry: dont retry on errors.

I just relased a new version of IceDoctor (right before reading this.. )
http://blubbedev.net/icefs/dl/IceDoctor-1.2.lha
Fixed problem with large files.

Quote:

Not mutually exclusive.

Multiple drawers are created if there would otherwise be
name collisions. If you didnt save the log, or used the browser,
only way no to know now what has changed is to look around..

Quote:
So can you change IceDoctor not eating up almost 500MB of RAM? We have no virtual memory, so it is up to the application to not eat up all memory.

Quote:
Even mor e as all modern features like memory protection, resource tracking and virtual memory are not available in MOS. Thanks for looking at it.

Quote:
There were no large files on this harddrive yet. Only "old" Amiga files and some archives upto 2GB at the max. So I guess this won't change anything for us here.

Quote:

I saved the log but it only says things like:


Scanning directory tree and file extents.. 2981621
Entry "ÍX" @ $B6F689B7C0 could not be healed
Rebuilding directory "<root>"..
Rebuilt 24 entries.
2768407 files, 213213 dirs, 0 softlinks, 0 hardfiles, 0 harddirs.
0 fixes applied.
Done.

Searching for orphaned files.. 2773912
Freed file extent @ $B6F68F3000
Freed file extent @ $B6F723E000
moving 8229 orphaned entries..
into directory ".orphaned".
into directory ".orphaned_F6673B24".
into directory ".orphaned_F6677221".

and so on. Then it says:
Updating bitmaps.. 7853
updated bitmap @ $20040
updated bitmap @ $502D6A0040
updated bitmap @ $5149960040
updated bitmap @ $51ABE80040

and so on.

So there are no hints which directories and files are touched. So no hint why there should be any name collisions. And why should there be name collisions if there have not been any before the volume was no more accessable? AmigaDOS prevents you from copying two files with the same name to the same directory.
Also, I don't know what this Entry "ÍX" is. No file has this kind of name on my harddrive.

Next ugly bug!
I let Ambient calculate folder sizes of all .orphaned directories on this drive. I walked through those .orphaned directories. THe first one is named .orphaned and it says to not contain any data, no directory, no file. The other ones like .orphaned_F66B1070 contain just a handful of files, mostly 2 to 5. So I deleted the empty drawer to look after those files one by one whether I have them in another directory or not.
Although the drawer was displayed as empty, after I pressed the delete button suddenly Ambeint told me which files it deletes now! And the progresbar was really short compared to where it wanted to end! I immediately stopped, checked again inside this draawer and there are STILL no files and drawers displayed. I checked file info (drawer info) again and this time it tells me that this drawer contains 39GB of data! Even worse: although I immediately canceled the deletion of this drawer before those 39GB could be deleted completely, the drawer has gone. I went to .recycled/ and checked but there are just 16 files with 1.1GB.

You should let the user choose the number of .recycled/ files when he is installing the drive. Otherwise he will not know about it being just 16 files which is too few. I only found out by looking into IceConfig ... now, when it already was too late because there was no proper hint that only 16 files will be kept. You could add that hint to the readme where you descirbe "Max recycled files". This default setting is not optimal. At least the default max recycled bytes is set to no limit.

Also, all the files within .recycled/ have an additional suffix like .59D or .59E. Is this an information where these files come from to restore them to the original direcotry or what is it? I did not find anything about in IceFS.readme or in Ice2Layout.pdf or somewhere else.

After I have changed the max transfer to 0x20000, I still get the same behaviour. Mirrorcopy and Ambient both stop while copying files. Machine was shutdown in the meantime.

Also, when calculating the directory size with Ambient it can happen that Ambeint ends up with a waiting cursor and no more returns. Had this several times now although most of the time it works. I can not say if it comes from IceFS or Ambient. I just can say that it happens multiple times.

EDIT:
Also, Mirrorcopy does not react on ctrl-c. When it stops copying files the cpu usage goes down but you cannot break mirrocopy in shell window.

[ Edited by connor On 2011/11/27 15:43 ]

EDIT2:
Next mirrorcopy problem. If after a reset you start mirrorcopy again it falls over files that it has already copied if their filenames are too long. I have a file that has a name with 107 characters. 107 characters are allowed by Ambient. The file got completely copied last time (tested with both Ambient and mirrorcopy). The timesamp is the original one. Mirrorcopy stopped at another file the run before in a totally different drawer. When I reactivate mirrorcopy, it says that it cannot delete this files but shortened to 106 chararcters. Instead of "mylongfilename.mp3" it says:
error: delete "mylongfilename.mp"
Fault: Object not found

Then it stops the whole copy process and returns to shell.

What is the use of deleting a file from the target drive that has already been copied?
Why is the filename shortened? Of course this file cannot be found as it has never been created. So why to look for it?
Why does mirrorcopy stop only because it cannot find a file on the target side where its task is to copy files from source to target but not to delete files at the target? I would expect that I end up with two files with similar names instead but this does not happen.

Also strange is that I cannot delete the file with 107 characters in Amibent anymore. When I hit delete button nothing happens. It even does not give a message. Just nothing. When I shorten the filename by one character and save it then I can delete the file.

[ Edited by connor On 2011/11/27 16:10 ]

Quote:

Orphaned files do not have their parent directories around
anymore. So you can understand that two orphaned files
xxx/yy and aaa/yy will then collide name wise when put in orphaned directory. So there are then two choises, automatically rename then files themselves or put them in separate orphaned directories, icedoctor chooses latter.

The weird name is there because your volume is trashed for some reason, likely hardware/driver issue. Anything can happen then,
for example trashing of the name of a file.

Quote:

Well, sounds like you forgot to "show all".

Quote:

Sure, good idea. could change it to 128 or so.

Quote:

No, just semi-random numbers used to avoid name collisions.

Quote:

Ok. Good point. It does react but only between each file copy.


Quote:

I'll see if mirrorcopy has some 107 character bug.

Quote:

MirrorCopy creates a mirror, that involves removing files also.
This behaviour can be disabled using NODEL option.

Quote:

No idea..

Quote:
As I said, the drive works perfectly with other OSes and filesystems. It works perfectly in the same machine with same MOS and just used SFS instead of IceFS. Both use the same driver (sata.device). So where is the difference then besides ICeFS? I don't see one yet.
The weird names have just those two suffixes so far, no others occured yet. If there were really that trashed then I would expect them to not be that systematically and clean renamed but totally random.

Quote:
No. I always display Ambient listers with show all. I double-checked. As I said, I also let Ambient claculate the directory size. It also showed two zeros for files and directories. And even if you change from show all to icon view only and do not see a single icon you always get the result in the bottom line. This one was said to be zero files and zero directories, too. You can always check yourself by opening RAM disk icon. Zero files but 3 direcotiries.

Quote:
I set it to the maximum of 16384 to look back as much as possible.

Quote:
I see. So because of the target file got a wrong name during (mirror)copying (for whatever reason, the target path is even shorter than the source path) which cannot be deleted (for whatever reason) mirrorcopy does not know what to do and stops.

EDIT:
By the way, in "verbose" mode mirrorcopy works a lot longer than without that switch. Without it it stops after maximum 3 minutes, sometimes even after seconds. With verbose switch on it copies 20, 30 minutes most of the time but then also stops.

[ Edited by connor On 2011/11/27 17:44 ]

Quote:

Verbose mode only adds a printf for each file, so any big
difference you have noticed would be down to something else entirely.

Quote:

Fact is that it works way better with verbose set on then with verbose set off. It is still not what it should be like but at leaast I do not have to reboot several hundred times to copy all files but maybe 10 reboots.

Installed a second harddrive with IceFS, this time it says it is formatted with IceFS 2.8. I copy contents from 2.7-IOceFS to 2.8-IceFS. Mirrorcopy says:

Error: lock "
Ms@
MrÐ!ãa€"
Fault: Objekt not found

normal copy and Ambient copy stop copying again every few files.

What is this weird lock that it cannot find but want to copy/delete/whatever?

Next bug:

files inside .recycled dir cannot be delted or renamed when their filename is 105 characters or longer. When they get moved there, IceFS adds this .59D suffix at the end of the filename. This makes filenames invalid so they cannot be renamed or deleeted anymore and waste harddrive space forever.
When you hit del key on your keyboard Ambient says just nothing. When you want to rename them it says "Object is not of expected type (#212)". If you say "delete toolongfilename" in shell it says "no file to delete".

Quote:

No. They wont waste harddrive space forever.
Try rm command, if you have the SDK.
Delete command cant handle filenames longer than 107,
Ambient might be same.
But why are you deleting files in .recycled dir anyway ?
These files will get removed when dir is full.

Quote:

Sounds like the usual crap.

Quote:
What do you mean? The name of the lock sounds really weird. I had expected it to be the name of a file or drawer. This is why I switched back to normal Ambient copy because I wanted to see when any strange filenames get copied.

Quote:

I say usual crap because, it looks like yet more trashed meta
somewhere. Could also be some bug in mirrorcopy i guess.
But then you say ambient stalls when copying too the volume.
Well, maybe the volume f*cked ? Again. And as long as something is trashing your volumes into bits, these kinds
of errors are going to appear. And I still can't say what is the
problem. I can just conclude that more crap is happening.
Until I can somehow reproduce these problems I really have no idea.

Quote:
Yes, rm from SDK does the job. So MOS and Ambient internal commands (at least delete command) need a little tune up to handle files with larger filenames.
I tried deleting them to get a feeling how reliable IceFS works. I'm still in the testing process to see if I can put my data on it for real life. It would have taken a long time to get this dir "full", so I wanted to be sure that they can be deleted.

Hi, I do also have a problem since 2.8, as it is not possible anymore to burn a data dvd from data coming from an 2-terra external HD which has IceFS 2.8 on it. I burned with FryingPan before and now on an Pegasos2 with MorphOS 2.6 installed. I did not change anything between the last burn with IceFS 2.7 and now, with IceFS 2.8. What happens is that the burning process stops and the system is completely blocked and I have to reset.

After copying all files from the IceFS 2.7 to the IceFS 2.8 drive I formatted 2.7 to 2.8 to return all files and see if I get less errors. But it does not change for copying. It interrupts all the time, most ly I cannot even copy three files before it stalls. Now I even get new errors: Meta error: Self ideotification failed when reading meta @ 10EF8AF140 [tag 6]
(a.v.: adr $EF8AF140 tag 6 size 128)
Then I have to hit Retry or Cancel

What is this?