Text file corrupted when dragged from RAM to USB pen

[samo79]

Ok, i have this problem from time to time almost since the release of the Update 1 but i decide to write it now as the Update 3 is here

I always thinked that problem was caused by CrossDOS but it seems i have the same issue even now with the latest update, well let's explain in detail:

When i have a crash usually i tend to save my Grim Reaper log in RAM to check it later, now if i drag this txt file directly from RAM to my USB pen (the one is a Transcend 2 GB) the text of the Grim Reaper log will be corrupted so it will become unreadable

See this grab: http://imageshack.us/photo/my-images/571/logx.png/

I did also an experiment: I try to redirect the Grim Reaper path directly to my USB pen and i note that this problem does not happen, almost for my experience.

I can be able to reproduce this bug almost at 50% of time (so quite often) but aniway if you want to try to reproduce it on your machine do the follow step by step guide

1 - Attach an USB pen on your Amiga
2 - Found a program or a function that usually crash
3 - When your app crash, save your GR log in RAM
4 - Now drag your GrimReaper log (txt file) in your USB pen
5 - Open it directly from your USB pen using MultiView

Note that if you try to drag again the GR log from RAM to USB (so overwriting it) the txt will be open correctly (no corruption)

Hope that help

[nbache]

My first thought when reading this description is, okay, he's complaining that right after a crash, sometimes a file in RAM: gets corrupted when dragging it to a USB stick. Well, yeah, that's the situation after something crashes, can't be helped. The system is per definition in an undefined and sometimes dangerous state.

That said, it is interesting that you say that the file can be dragged again later without corruption. Is that correctly understood?

What happens if you just place a GrimReaper log (saved at an earlier occasion) in RAM: and try dragging it to your stick?

What about some other text file, or does it only happen with GR logs?

If it only happens right after an actual crash (i.e. your experiment above with a file saved earlier didn't show the problem), does it have to be any special kind of crash, or is there any special program which is more likely to crash in a way that produces the problem than others?

What happens if you set GrimReaper to save the crashlog on your HD (use a non-important partition if you can, so validtaion - if FFS - is not too much of a bother), and then drag it from there to the stick?

Oh, and what if you open the file directly in RAM: with MultiView right after the crash, is it corrupt already there?

All these questions - and more - to be answered in the next episode of ...

Best regards,

Niels

[samo79]

Well first of all, i know and you are right that the general situation is a bit messy and not very ideal to give a report, but the evidence is that if you get a text corruption some problems still somewhere or not ?

That said, it is interesting that you say that the file can be dragged again later without corruption. Is that correctly understood?

Yes exactly

What happens if you just place a GrimReaper log (saved at an earlier occasion) in RAM: and try dragging it to your stick?

This is exactly what i did and what i reported

What about some other text file, or does it only happen with GR logs?

Well i didn't try it, but i can try

If it only happens right after an actual crash (i.e. your experiment above with a file saved earlier didn't show the problem), does it have to be any special kind of crash, or is there any special program which is more likely to crash in a way that produces the problem than others?

You can try with MUI OWB opening the bookmark, here it crash always but if you have other example programs you can try as well, there are tons of crashy example on AmigaOS (sadly)

What happens if you set GrimReaper to save the crashlog on your HD (use a non-important partition if you can, so validtaion - if FFS - is not too much of a bother), and then drag it from there to the stick?

It's the same

Oh, and what if you open the file directly in RAM: with MultiView right after the crash, is it corrupt already there?

No, the text file will be corrupted only after saving it to the USB pen

All these questions - and more - to be answered in the next episode of ...

LOL, my episode was released in advance

[nbache]

Well first of all, i know and you are right that the general situation is a bit messy and not very ideal to give a report, but the evidence is that if you get a text corruption some problems still somewhere or not ?

Yes, and that's what I'm trying to get further clues on by these questions.

What happens if you just place a GrimReaper log (saved at an earlier occasion) in RAM: and try dragging it to your stick?

This is exactly what i did and what i reported

Well, what I meant was what if you do these steps:

1. Get the crash, save the crash log and copy it to your HD.
2. Reboot your machine.
3. Copy the previously saved log to RAM: and drag it from there to your stick.

I'm trying to find out whether the fact that the system is in a post-crash state has any influence on the corruption. If it still gets corrupted in the test I describe here where the system is freshly booted and has not crashed, then the corruption doesn't have anything to do with the crash, which is possibly an important clue.

What about some other text file, or does it only happen with GR logs?

Well i didn't try it, but i can try

Yes, please do. This is the other side of the attempt to figure out which of the factors described have a real influence and which don't.

Interesting results so far, but let's see what the next couple of tests give.

Best regards,

Niels

[tbreeden]

I had something very similar happen yesterday.

Like you I had the GR save a crashlog to ram:

In my case, however, I dragged the crashlog icon over onto an SFS hard disk partition directory.

The file did not appear in the target workbench window at all, but did appear if I did a CLI List command to list the contents of the directory.

A second or third drag from ram: did seem to cause it to appear in the hard disk directory, and be readable.

I was confused, but I think that is the way it happened. I will try to duplicate it.

Tom

[samo79]

1. Get the crash, save the crash log and copy it to your HD.
2. Reboot your machine.
3. Copy the previously saved log to RAM: and drag it from there to your stick.

I'm trying to find out whether the fact that the system is in a post-crash state has any influence on the corruption. If it still gets corrupted in the test I describe here where the system is freshly booted and has not crashed, then the corruption doesn't have anything to do with the crash, which is possibly an important clue.

Ok i did it and the crashlog will never corrupted as is, it will corrupted dragging the log file into the USB device only during the crash state of the machine, but ...

If you redrag it on USB device again (overwriting the corrupted crashlog) you will get a correct file

So to summarize:

- Crashlog is corrupted when drag this txt file from RAM: to an USB Device (during a crash state of the machine)
- If you just overwriting it again all curruption problem will be solved

So first dragged file will be corrupted for some strange reason, a small USB or CrossDOS bug

[ChrisH]

Ok i did it and the crashlog will never corrupted as is, it will corrupted dragging the log file into the USB device only during the crash state of the machine, but ...

...

So first dragged file will be corrupted for some strange reason, a small USB or CrossDOS bug

I'm not sure you could call corruption during a crash state a "bug", unless it happens for all kinds of crashes (rather than just a specific crash that might be corrupting memory in a specific way). So what kinds of crash(es) have you seen corruption with?

[samo79]

It happen for all type of crash, i mean: if an application (any type of application) will crash, then if i copy the log to RAM and then drag it to my USB Pen i have as a result this txt (generated by the GR tool) corrupted ...

Next time i will try to post here this type of corrupted file ...

[tbreeden]

I'm not sure you could call corruption during a crash state a "bug", unless it happens for all kinds of crashes (rather than just a specific crash that might be corrupting memory in a specific way). So what kinds of crash(es) have you seen corruption with?

FWIW, the problems I was seeing with the crashlog - not the same as samo79's - were not limited to the USB drive, and were certainly due to a bad state of Intuition or DOS. The crash log was being written by GR ok, but I could not copy it anywhere without rebooting.

Tom

[samo79]

Unfortunely bug still present even on AmigaOS 4.1 Final Edition and i was able to reproduce it just dragging a simple txt file in my USB penstick

Reproduce it seems not easy because sometimes happen and sometimes not, maybe it's all related to the state of your machine in that particular moment, however what i did was just this:

1 - I open the window (the partition) when reside my USB stick
2 - I dragged a txt file into it (using the mouse)
3 - Finally i just double click into it in order to open it --> text context was now completely corrupted (almost unreadable and full of strange symbols)

But if i close and then (re)open it again the text corruption simply gone ... but at first step often i got this strange text corruption !
Quite probably there is a little bug somewhere in the USB driver