Corrupted file on Saving

[fae_alba]

For the second time I've had A:M hiccup and save an empty file of a model I had been working on. The model exists on screen, but what is saved is looks like this:

 

ProductVersion=17

Release= PC

FileInfoPos=162746

 

This obviously is wrong. I would suggest a warning message be displayed and a prompt to continue before actually destroying what is on disk. Fortunately I didn't lose much work, but it is frustrating when it does happen, and could be (and has been) catastrophic.

 

Just sayin.

[Rodney]

Paul,

You'll need to be more specific about what was happening when this errant file was created.

Deciphering what your 'hiccup' was is going to be a pretty wide area to traverse.

 

I do agree that having A:M save files at critical times is a good idea but this saving can also be detrimental if it overwrites a 'better' file.

I'd love to see A:M save a copy of the current project into the same folder that it will render into for instance immediately before rendering.

This would serve several purposes:

 

1) If something goes wrong, such as a crash upon rendering, the saved file could simply be reopened.

2) It would be really easy to open a file and rerender a shot or scene because it'd be right there in the render folder.

 

I must say that I have never had A:M produce a file like you show but then again my requirements aren't as computer intensive as many folks.

Where I tend to lose files is when I launch a render without saving first.

 

The part that intrigues me about your case is that there are several variables that aren't accounted for.

For instance, are you saving to a network folder or local harddrive?

Are you saving to a new file or attempting to save over an old one?

When you save your files do you number them incrementally or use the same name as before?

 

There are a lot of variables to reduce before this 'cure this hiccup' can become a actionable suggestion for inclusion in a future version.

 

Added:

 

The model exists on screen,

 

This is definitely something worth looking at more closely.

I assume you are suggesting that if you were to save the model again the file might then contain the same data as what is displayed on screen?

I'm not sure.

 

I would suggest a warning message be displayed and a prompt to continue before actually destroying what is on disk.

 

A:M does this every time we select "Save As' and attempt to overwrite an existing file.

I have never trusted direct saves in any program and definitely don't trust Save icons (who knows where those really go?... and worst of all... they are intentionally designed to automate (and take the user out of the process) of Overwrite and Destroy!).

At least when using 'Save As' the program lets you be in control.

And when something inevitably fails you'll know it was you and not the computer.

[robcat2075]

I would suggest a warning message be displayed and a prompt to continue before actually destroying what is on disk.

 

I'm not sure what more to do.

 

There's two ways to Save in Windows, of course.

 

"Save As" always warns/prompts you if you are saving to an identical filename.

 

"Save" always resaves with the current filename, so you already know it's writing over something. Is more warning needed for that?

 

I almost never use "Save", I've been doing "Save As" with a manually incremented filename for years and I've not had a problem with that.

[fae_alba]

Paul,

You'll need to be more specific about what was happening when this errant file was created.

Deciphering what your 'hiccup' was is going to be a pretty wide area to traverse.

 

the only thing ontoward was a slow down in response time. My usual process is to save the model/project, close am then restart. No errors, no warnings. The model saved as the empty file.

 

I do agree that having A:M save files at critical times is a good idea but this saving can also be detrimental if it overwrites a 'better' file.

I'd love to see A:M save a copy of the current project into the same folder that it will render into for instance immediately before rendering.

This would serve several purposes:

 

1) If something goes wrong, such as a crash upon rendering, the saved file could simply be reopened.

2) It would be really easy to open a file and rerender a shot or scene because it'd be right there in the render folder.

 

I do have the backup option turned on, but it doesn't seem to work. No files are being written.

 

I must say that I have never had A:M produce a file like you show but then again my requirements aren't as computer intensive as many folks.

Where I tend to lose files is when I launch a render without saving first.

 

The part that intrigues me about your case is that there are several variables that aren't accounted for.

For instance, are you saving to a network folder or local harddrive?

Are you saving to a new file or attempting to save over an old one?

When you save your files do you number them incrementally or use the same name as before?

 

There are a lot of variables to reduce before this 'cure this hiccup' can become a actionable suggestion for inclusion in a future version.

 

Local folder, saving over existing file. When I reach a "milestone" in the model, I make a copy of it as a backup

 

Added:

 

The model exists on screen,

 

This is definitely something worth looking at more closely.

I assume you are suggesting that if you were to save the model again the file might then contain the same data as what is displayed on screen?

I'm not sure.

 

I don't think that is true. Putting on my developer hat, it feels like there is a disconnect with what is being used to "draw" on the screen, and what is being used when saving the file. Variables or memory registers, are getting re-initialized in error under some condition not being reflected to the user. When that happens, saving as a new file name wouldn't help. When this happened last, I saved multiple times. Since you have no warning when this is happening, you have no idea that you need to react.

 

I would suggest a warning message be displayed and a prompt to continue before actually destroying what is on disk.

 

A:M does this every time we select "Save As' and attempt to overwrite an existing file.

I have never trusted direct saves in any program and definitely don't trust Save icons (who knows where those really go?... and worst of all... they are intentionally designed to automate (and take the user out of the process) of Overwrite and Destroy!).

At least when using 'Save As' the program lets you be in control.

And when something inevitably fails you'll know it was you and not the computer.

 

That's not a bad idea, but again, under this particular case, I don't think it would save the model. I think a check for an empty file when using the Save option before writing to disk is a good one. If the user chooses to create a new model, and before doing anything wants to save the empty model, they wouldn't get a warning, since the Save option is disabled on new models.

[robcat2075]

If the user chooses to create a new model, and before doing anything wants to save the empty model, they wouldn't get a warning, since the Save option is disabled on new models.

 

I don't understand the problem.

 

A new model starts out with a default name of Model1.mdl

 

The first time you try to save that you have to do "Save As" and if there already is a Model1.mdl in the dir you are saving to you will get a warning.

 

 

Now, if you saved a model either with Save or Save As and got only a blank model file on the disk... that's a separate problem from this warning stuff, that's an outright bug some sort.

 

 

Just as a general note, I almost never save an MDL or an other asset separately. When I'm developing things I save entire PRJs with everything embedded and I never resave over a previous filename. That way my entire development environment is all in one file and if I need to go back to a previous version i don't have to worry that some change I made in a separately saved material or action or whatever will be loaded by that previous version of my project and make that older version of my project be not like the way it was before.

 

Disk space is cheap, it doesn't bother me that this everything-in-PRJs approach uses up a bit more.

 

If i later need to take a model or material to another project, I will save them out separately, just long enough to load them in the new PRJ and embed them. Then i'm back to saving whole environments again as PRJs.

 

For me, this is the safest workflow and I haven't had any saving mishaps or confusion with it.

[Rodney]

I do have the backup option turned on, but it doesn't seem to work. No files are being written.

 

If it doesn't seem to work I'd turn it off.

At least until it can be determined to work.

 

the only thing ontoward was a slow down in response time. My usual process is to save the model/project, close am then restart. No errors, no warnings. The model saved as the empty file.

 

If A:M closed before it could save the file then I can see how that file might be corrupted.

A slowed down response time usually indicates lack of available memory for programs to operate with.

While it's a good idea to close down programs that aren't being used to free up memory closing the program down that you are trying to save files from can be a dangerous proposition.

Better to take a break... go away for awhile... and allow the program to save the file.

If it is still not saved upon return then that iteration is likely a lost cause and a previous state will need to be returned to.

 

Local folder, saving over existing file.

Here is what I would like to see you do (assuming you wish to continue overwriting your files the way you do): 'Save As' first to another filename and then go back and save over the top of the original.

After doing this for a few days/weeks you'll instinctively stop doing that second part.

 

A lot could be said about saving but the best advise I can give is, "Save often and incrementally."

Think of it as creating 'dailies'... heck create a new folder each time with today's current date on it when you first go to work.

A workflow like this may suffice until operating systems seamlessly iterate file updates for us.

 

When I reach a "milestone" in the model, I make a copy of it as a backup

 

I assume by this you mean that you use the OS to create a copy of the file or directory.

I don't find this to be a reliable approach for one reason in particular; you may not copy all of the required files you need with your project.

Problems in this area can generally be avoided using the 'Save incrementally' approach.

Some resources may not immediately load if you move them but they will still usually be somewhere close.

 

It feels like there is a disconnect with what is being used to "draw" on the screen, and what is being used when saving the file.

 

This appears to be the area we need to focus on more closely.

There are a lot of variables to consider but one important variable would be how often you save.

The longer in between saves the more tenuous the end results.

If you don't save often that goes against the best practice of 'Save often and incrementally' and I can only refer you back to that proven workflow.

 

I think a check for an empty file when using the Save option before writing to disk is a good one.

 

I hear you but...

As far as I know the Save option assumes an empty/missing file. If the file is there it assumes you want it written over.

Save As assumes you have more instructions and will initiate a process to protect files from being overwritten.

 

'Save' means you want what was there previously to go away... which is usually NOT what we want. (We would at least like to be able to reference that earlier version)

Using 'Save' then opens you up to all manner of things outside of your... and A:M's control.

For instance, a power surge, power outage, corrupted memory, read only data location... this last one is a biggy if you initiated a session from a read only location, etc. etc., etc. etc...

 

In case I've failed to mention this before: Save often and incrementally.

[robcat2075]

In case I've failed to mention this before: Save often and incrementally.

 

Make that, "Save As" often and incrementally.

 

 

Maybe we should just get rid of the "Save" button and no one will be able to casually save over an old file without wanting to.

[fae_alba]

You guys are missing the point: There is a bug, without a doubt. That bug is saving a blank file when there is one in the current model being saved. The how/why/frequency to that I cannot say. It has happened to me, twice in the last three - four months, both in version 17 (I can't use 18 since it crashes with models and decals).

 

The save/save as/incremental suggestions are all well and good, But, even if save as with an incremental number is used, if am is saving blank files without any warning, then I am still getting, well blank files. Regardless of how many different copies I've saved. And yes, at some point there would be a version that is still good, the question is, how much work would be lost that you wouldn't know about until you actually went back in on another day and discovered the empty file.

 

I don't think memory is the issue. My laptop has 8gb ram, and I usually only have at most, A:M and perhaps a browser open.

[Rodney]

You guys are missing the point: There is a bug, without a doubt.

 

No point missed here. If there is a bug then wth the right information it can be tracked down and fixed.

Or perhaps I should say, if it can be reproduced it can be documented. If it can be documented it can be fixed.

It is that ability to reproduce a bug that we are after here... and trying to reduce variables by suggesting workflows that fully rule out user error.

 

Which leads us back to your first post and my response.

Reducing the variables will help.

 

Note that this is why A:M Reports is the place to collect bug reporting information as it collects such things as:

What version is this occurring in?

What operating system?

Does it occur anywhere else (i.e. can it be reproduced in an earlier or later version)?

What exactly were you doing at the time (immediately before saving)? (i.e. Was it dealing with cloth and simulation?)

What was (or would be) the file size if the file had been properly saved?

What steps can be walked through to reproduce the error?

What files can be used to replicate the error?

Etc.

 

If this is a bug that only happens every 4 months or so is there something you do (or fail to do) every four months or so that triggers it?

Rhetorical question... there would have to be.

 

Do you have any steps that will or are likely to reproduce this bug?

Suggesting that Steffen should continuously save files until something odd happens isn't a very good option. (Although I suppose that could be tried)

 

 

 

Make that, "Save As" often and incrementally. wink.gif

 

Thanks Robert. I will try to assimilate that!

 

Added: One thing that posting here in the forum does that on the surface A:M Reports does not is confirm a user experience.

If others are having the same issue then we can narrow the field down, identify the real problem and discover the underlying cause to it.

This can be accomplished in A:M Reports as well due primarily to the nature of multiple reports that will circle around a specific bug until it is fixed but that confirmation may not happen as quickly as it can when the problem is discussed via chat or forum.

[robcat2075]

But, even if save as with an incremental number is used, if am is saving blank files without any warning, then I am still getting, well blank files. Regardless of how many different copies I've saved. And yes, at some point there would be a version that is still good, the question is, how much work would be lost that you wouldn't know about until you actually went back in on another day and discovered the empty file.

 

 

So it's not just one blank file, you've got dozens of blank files.

 

It is baffling because I've never had it happen in 10 years of using A:M almost every day. Not even in the gazillion files I saved while working on TWO.

 

For now, turn off auto save, do only "Save As", never use "save", and every hour look at that directory to see if suddenly the file got smaller after a certain save.

 

Set a timer to remind you to do it.

[Rodney]

So it's not just one blank file, you've got dozens of blank files.

 

It is baffling because I've never had it happen in 10 years of using A:M almost every day. Not even in the gazillion files I saved while working on TWO.

 

For now, turn off auto save, do only "Save As", never use "save", and every hour look at that directory to see if suddenly the file got smaller after a certain save.

 

Set a timer to remind you to do it.

 

At first I thought you were being facetious Robert but that actually makes sense.

If there is a particular file that is more likely to produce the error that also could be shared so others can set their save timers as well.

The downside: At present this error appears to only be happening on Paul's system so it may be hard to replicate by someone else.

 

Added: Problems with saving don't trouble me... my problem is remembering WHERE I saved things.

[Mechadelphia]

Hi Paul,

 

I encountered something similar but not exactly the same as your experience in v17.

 

In my case, I had been doing something a bit obscure to make that happen so it was easy to figure out how to repeat it (I was trying to use expressions in a way that was not intended). It was fixed afterwards but I don't remember the report number offhand. Are you doing somethings with the model that are a little non-standard or are you working as you always have?

 

I would suggest a warning message be displayed and a prompt to continue before actually destroying what is on disk.

 

Are you serious or are you saying this out of frustration?

 

If you want this fixed then you should report this at A:M Reports. To get that problem fixed you'll need to be able to reproduce what you are talking about in v18 though since v17 is no longer being worked on. Or at least try to figure out how to repeat it in v17 so that someone can try it in v18 to see if they can reproduce it and then report it.

 

You said that v18 crashes with models and decals so you can't work on it there. On my end, I have not run into that problem in v18 at this point. Have you reported that issue or do you know if it has been reported for v18 in A:M Reports?

 

The save/save as/incremental suggestions are all well and good, But, even if save as with an incremental number is used, if am is saving blank files without any warning, then I am still getting, well blank files. Regardless of how many different copies I've saved.

 

I don't get the impression that this is what is happening to you but if you save incrementally and save consecutive blank files then report that right away (and include the file(s) in question) even if you don't know how to reproduce the occurrence.

 

If you aren't saving incrementally then you should start. Even outside of A:M.

 

Anyway, I know that trying to reproduce these types of things so that it can be reported can be time consuming but if you are dealing with a bug this critical and want to have it fixed then this is the only way. If you are willing to sort it all out here at the forums before reporting it then attach a copy of the last file that had data in it before it was wiped. If you can provide at least a vague description of what you were doing before the problem occurred then maybe a few users will try a few things out to see if they can help.