Save as does not save in LDCad 1.5?

[Jaco van der Molen]

Hi Roland,

Is it me, or does LDCad not write a file when I "save as..."
I edited a file, saved it with another name, closed LDCad, restarted it later: no new file?

Jaco

[Roland Melkert]

Hi Roland,

Is it me, or does LDCad not write a file when I "save as..."
I edited a file, saved it with another name, closed LDCad, restarted it later: no new file?

Jaco

As far I know it works like expected (did a small test to be sure).

Maybe you put it somewhere different, is it listed in the recent list?

[Jaco van der Molen]

Maybe you put it somewhere different, is it listed in the recent list?

Nope, I searched my whole machine for the filename and did not find it.
Nor is the file listed in the recent file list.
I'll double check tomorrow.

[Jaco van der Molen]

After some research, Here is what's happening: when I save as the file and path is shown in the window.
If I just close LDCad, the file is not written. It is not to be found in on the drive and folder I specified.
Re-opening LDCad the new file is not in de recent file list.
If I save as and first choose close from the file menu and the quit LDCad, the file is written and reopening LDCad at the top of the recent file list and the newly saved file is present on the drive and in the folder I want....

[Roland Melkert]

After some research, Here is what's happening: when I save as the file and path is shown in the window.
If I just close LDCad, the file is not written. It is not to be found in on the drive and folder I specified.
Re-opening LDCad the new file is not in de recent file list.
If I save as and first choose close from the file menu and the quit LDCad, the file is written and reopening LDCad at the top of the recent file list and the newly saved file is present on the drive and in the folder I want....

This sounds very strange, is this a new file or an existing one?

Could you send me the original file so I might replicate it. And the log file from a problem run might give some insight to.

[Jaco van der Molen]

Any file. Only first time creation does work, eg. start a new file and save (as).
But saving an existing file under a different name and/or drive and/or folder simply does not create a file.

The only thing I think can confuse is most of the time I simply create a new model by starting a new file and immediately start building like it was a normal LDR file. Then in the progress of building I end up with some submodels and then I save as MPD with extension .mpd.
Perhaps that is the problem.

I tested on two machines (work and home).

I'll take some screenshots or screencapture a movie illustrating the problem tomorrow.

[Jaco van der Molen]

See video:
https://www.youtube.com/watch?v=DgDVna-Fkk8
Now closing the file and then close LCDad does not even save the file!

[Philippe Hurbain]

A weird issue. At first I thought it was a problem specific to Jaco's machine as I could't reproduce it, but now I did... sometimes, depending on the model. In the archive attached, the mine loader doesn't "save as" while the fire plane does. Log file also included.

[Merlijn Wissink]

I think it just is a Windows permissions issue. You're trying to save the file somewhere in a folder in the C root.

I've just tried the same and both save and save as don't work for a location like that, unless I start LDCad as administrator.

[Jaco van der Molen]

@ Philo: I just noticed too that it is not the case with all models. Some work, some don't.
@ Merlijn: I am full admin on all my machines and can write any file in any folder on C: drive. On my laptop home I have a D: drive partitioned as Data drive and files don't save there too.
@ Roland: good luck solving this problem :-)
@ Me: verify if the file saved. I lost some work due this "bug"... :-)

[Roland Melkert]

@ Philo: I just noticed too that it is not the case with all models. Some work, some don't.
@ Merlijn: I am full admin on all my machines and can write any file in any folder on C: drive. On my laptop home I have a D: drive partitioned as Data drive and files don't save there too.
@ Roland: good luck solving this problem :-)
@ Me: verify if the file saved. I lost some work due this "bug"... :-)

Unfortunately I could save both Philo's models and his zipped logfile doesn't mention a save operation (wrong log file?)

So I went into the source to see if something can go wrong after the filename dialog stage, the only thing I found is a check on changes. Which means it won't save if there are no changes since the last save even for save as so it seems.

But you report lost work so it can't be that alone :

[Travis Cobbs]

@ Philo: I just noticed too that it is not the case with all models. Some work, some don't.
@ Merlijn: I am full admin on all my machines and can write any file in any folder on C: drive. On my laptop home I have a D: drive partitioned as Data drive and files don't save there too.
@ Roland: good luck solving this problem :-)
@ Me: verify if the file saved. I lost some work due this "bug"... :-)

Unless you have totally disabled UAC, or you're running Windows XP or earlier, then LDCad doesn't in fact have write access to write files to all folders on your C: drive, whether you're an admin or not. As a side note, I would personally advise against totally disabling UAC, but if you want to treat Windows like it is XP, you need to do that (and live with the much higher likelihood of having your computer infected).

If it is indeed a permissions problem, then LDCad could solve it by detecting the failure and showing an error dialog when it occurs.

[Philippe Hurbain]

Unfortunately I could save both Philo's models and his zipped logfile doesn't mention a save operation (wrong log file?)

Sorry, I'll check again tomorrow...

If it is indeed a permissions problem, then LDCad could solve it by detecting the failure and showing an error dialog when it occurs.

AFAIK that's not the problem I had since I saved on my desktop (and moreover only one file didn't save, the other did).

[Jaco van der Molen]

Hmm, it could be that I had saved a file without making changes.
Still, I was able to save a file (cannot remember if I made changes then) to My Documents/Google Drive which is in fact on drive C: too.
I am running Windows 7 on both machines I use (home/work) and need some more testing.

[Merlijn Wissink]

Hmm, it could be that I had saved a file without making changes.
Still, I was able to save a file (cannot remember if I made changes then) to My Documents/Google Drive which is in fact on drive C: too.
I am running Windows 7 on both machines I use (home/work) and need some more testing.

The drive doesn't matter, the location (folder) does.
As a user, you have more rights and permissions in the my documents folder (and Google Drive, which is in de my Documents folder) than you have in a folder in the root C directory.

I'd advise you to at least try and run LDCad as administrator (right mouse button -> run as administrator in unlikely case you didn't know) to know for sure if that's the problem or not 

[Merlijn Wissink]

Unfortunately I could save both Philo's models and his zipped logfile doesn't mention a save operation (wrong log file?)

So I went into the source to see if something can go wrong after the filename dialog stage, the only thing I found is a check on changes. Which means it won't save if there are no changes since the last save even for save as so it seems.

But you report lost work so it can't be that alone :

So, when a user is done editing, then saves and after the save wants to do save-as, it won't work cause there are no changes since the last (normal) save? Do I understand that correctly?

If so, isn't that a bit undesired and not user-friendly?

[Roland Melkert]

If so, isn't that a bit undesired and not user-friendly?

Yes, it would report:

Code:

05876 | 2016-05-31_18:18:09 | Progress | LDraw file save | C:\Users\Roland\Documents\dddd.mpd | Starting
05877 | 2016-05-31_18:18:09 | Progress | LDraw file save | C:\Users\Roland\Documents\dddd.mpd | Main content has no changes, will not save to "C:\Users\Roland\Documents\dddd.mpd"
05878 | 2016-05-31_18:18:09 | Progress | LDraw file save | C:\Users\Roland\Documents\dddd.mpd | Done

But that's because it's a bug   just not the one we're looking for taking into account Jaco's reports.

It comes from the snap info editing changes I made where you would only want the shadow file to be saved leaving the original .dat unmodified timestamp wise. it is easily fixed though.

[Roland Melkert]

Hmm, it could be that I had saved a file without making changes.
Still, I was able to save a file (cannot remember if I made changes then) to My Documents/Google Drive which is in fact on drive C: too.
I am running Windows 7 on both machines I use (home/work) and need some more testing.

The drive doesn't matter, the location (folder) does.
As a user, you have more rights and permissions in the my documents folder (and Google Drive, which is in de my Documents folder) than you have in a folder in the root C directory.

I'd advise you to at least try and run LDCad as administrator (right mouse button -> run as administrator in unlikely case you didn't know) to know for sure if that's the problem or not 

If the filewrite actually failed you should get an message dialog saying it coudn't write to disk, I added that in 15 beta 1a.

[Philippe Hurbain]

It can't be a permission issue, since I had the problem on one file but not another (both reproductibly) in the same folder...

[Magnus Forsberg]

Did you search for it in the VirtualStore?

Don't know if this is related or not, but I experienced something similar recently. I made a part in LDDP and saved it were I usually save them, in my parts-folder in C:\Program Files (x86)\LDraw\My parts\... I made a new folder for it there. (I know that it is the wrong place, now that I have upgraded my machine to Win10. I haven't moved them yet).
LDDP did save it and I didn't get a warning about it being a protected place.
I then opened a explorer-window to look at the part in the folder I just made, but to my surprice it wasn't there. Neither the file, nor the folder. Strange.
I opened LDDP again and looked in the recent files, and there it was. Even stranger.
Missing, if I looked in the explorer window, but present from inside LDDP.

I made a search on my c: drive and found that my file was saved in a totaly different place:
C:\Users\Magnus\AppData\Local\VirtualStore\Program Files (x86)\LDraw\My parts\...

It seems that Win 10 is fooling LDDP to show a "fake" address when I save my files in a protected area, and instead saved my file somewere else.

[Jaco van der Molen]

OK, from what I can conclude from models that I have tested is that when you `save a file as` when no changes are made no file is written, like Roland suggested.
I am beginning to doubt my note that I lost progress on a model now. It could have been my mistake then.

However it still seems a bit weird to me that no file is written, since I sometimes just want to save a file to a different folder with another name without changing anything.

[Merlijn Wissink]

That's an interesting one!

Somewhere around here, I suggested running LDCad as administrator, because when I was testing Jaco's problem, I tried to save a file in the root C directory when not running as admin. I saved a file, I reopened LDCad and it was magically in the recent files list and it was openable, but I couldn't find it in Windows Explorer. When I restarted LDCad again, the file was gone.

However, it actually is hiding in the VirtualStore folder! I think you're on to something 

[Philippe Hurbain]

If so, isn't that a bit undesired and not user-friendly?

Yes, it would report:

Code:

05876 | 2016-05-31_18:18:09 | Progress | LDraw file save | C:\Users\Roland\Documents\dddd.mpd | Starting
05877 | 2016-05-31_18:18:09 | Progress | LDraw file save | C:\Users\Roland\Documents\dddd.mpd | Main content has no changes, will not save to "C:\Users\Roland\Documents\dddd.mpd"
05878 | 2016-05-31_18:18:09 | Progress | LDraw file save | C:\Users\Roland\Documents\dddd.mpd | Done

But that's because it's a bug   just not the one we're looking for taking into account Jaco's reports.

It comes from the snap info editing changes I made where you would only want the shadow file to be saved leaving the original .dat unmodified timestamp wise. it is easily fixed though.

OK, what I see is exactly this issue, "save as" doesn't do anything if nothing was changed in the file. The difference in behaviour between the two files (one is saved and not the other) is that one contains a rubber band that is regenerated, thus triggering a modification. And indeed the log file (hopefully the right one is attached this time!) shows

Code:

03672 | 2016-06-01_10:20:14 | Progress | LDraw file save | G:\Mes_documents\Bureau\plane.mpd | Starting
03673 | 2016-06-01_10:20:14 | Progress | LDraw file save | G:\Mes_documents\Bureau\plane.mpd | 42040 - rubberBandRound-1.ldr | Generating LDraw lines for path.
03674 | 2016-06-01_10:20:14 | Info     | LDraw file save | G:\Mes_documents\Bureau\plane.mpd | 42040 - rubberBandRound-1.ldr | Done, generated 442 lines.
03675 | 2016-06-01_10:20:14 | Progress | LDraw file save | G:\Mes_documents\Bureau\plane.mpd | Done
(snip)
04506 | 2016-06-01_10:20:38 | Progress | LDraw file save | G:\Mes_documents\Bureau\loader.mpd | Starting
04507 | 2016-06-01_10:20:38 | Progress | LDraw file save | G:\Mes_documents\Bureau\loader.mpd | Main content has no changes, will not save to "G:\Mes_documents\Bureau\loader.mpd"
04508 | 2016-06-01_10:20:38 | Progress | LDraw file save | G:\Mes_documents\Bureau\loader.mpd | Done

[Roland Melkert]

That's an interesting one!

Somewhere around here, I suggested running LDCad as administrator, because when I was testing Jaco's problem, I tried to save a file in the root C directory when not running as admin. I saved a file, I reopened LDCad and it was magically in the recent files list and it was openable, but I couldn't find it in Windows Explorer. When I restarted LDCad again, the file was gone.

However, it actually is hiding in the VirtualStore folder! I think you're on to something 

Non existing files will be removed from the recent list on startup. But virtual store ones should remain I think because as far programs concern they are located at the original location (like a symbolic link).

[Roland Melkert]

Thanks Philo,

I've fixed the issue in my current 1.6 code.

Also I consider the unnecessary regeneration another bug