Until now i liked XOJO...I hope to like it again

[Rolf_Schindler]

@ Ivan

I still believe that I have only Xojo 2022 release 2 installed, i found no other version on my PC.
about the corrupted files in binary:
It’s not nice, but good to know

[Rick_Araujo]

@Ivan_Tellez

If you have multiple releases installed and you open a file, it will be allways opened with the LAST INSTALLED release, not with the one you saved it nor with the latest released.

I always open the IDE of interest and load the desired project for such IDE from there, to avoid unnoticed mismatching mistakes.

[Rolf_Schindler]

I finally found a solution to restore the corrupted project file:
In a Hex editor I deleted everything in the corrupted project file before:
runAInt …Padn
Then I copied from an older, working project file everything til:
runAInt …Padn
then inserting this at the beginning of the modified corrupted file.
The resulting project file is opening without any problems then

[Ian_Kennedy]

I’m glad it worked, but I really wouldn’t mess with binary files in this way. If you do make sure you have copies of everything you are working with.

[Sam_Rowlands]

@Sascha_S

Men don’t do backups! (But they cry often)

I thought real programmers wrote their own backup tools? Maybe that’s just me

[Tim_Jones]

@Ivan_Tellez

Corrupted files when saving is common (At least in binary and in windows), when working with Xojo, you get used to lose some work now and then.

This is one of the most disturbing and sad “accepted” issues with Xojo that I know of.

[Tim_Jones]

@Sam_Rowlands

I thought real programmers wrote their own backup tools? Maybe that’s just me

… and me!

[Greg_O]

@Tim_Jones

This is one of the most disturbing and sad “accepted” issues with Xojo that I know of.

I wouldn’t say “accepted”. When I was there, we took those cases very, very seriously. The problem is reproducing the issue. It’s fine to say “my project was corrupted” but when the IDE does the right thing 99.99% of the time, the answer usually points to “external factors”, and it’s almost impossible to replicate what was going on at that very moment.

In my experience, project corruption happens because of people saving their project in a cloud synced folder like DropBox, OneDrive or iCloud, thinking that it’s an easy version control or backup system. These services like to sync files as soon as they appear and sometimes they don’t check if a file is in use before they do so. I honestly don’t know if you can tell if a file that you created and are currently writing to has been locked by another service, and if you can, what it would do to the performance, having to check for every little write.

[KarenA]

@Greg_O

In my experience, project corruption happens because of people saving their project in a cloud synced folder like DropBox, OneDrive or iCloud, thinking that it’s an easy version control or backup system.

I had one such case of corruption in 2020 that I can recall … though there may have been others farther back. In that case Jason asked me to send him the project and I did.

In any case I can definitely say I have never done file syncing with any service (though I do have Time Machine turned on)

• Karen

[Greg_O]

@KarenA

had one such case of corruption in 2020 that I can recall

And I probably looked at it too, but seeing the problem and reproducing the issue is a little like looking at a car after an accident and being asked to figure out what caused the accident in the first place. Now if there had been several projects with the same corruption, that’s a pattern you can follow, but it was not uncommon to ask “how the heck did this project even get in this state when the IDE doesn’t even write data that way?”

[Sam_Rowlands]

@Greg_O

In my experience, project corruption happens because of people saving their project in a cloud synced folder like DropBox, OneDrive or iCloud, thinking that it’s an easy version control or backup system.

These services screw up App Wrapper processing of apps also. I added checks for at least iCloud (because I can), but eventually moved to an atomic processing system, where all the work is done the system temporary folder (on the same disk) and then moved to the final location upon completion. I haven’t had a problem with App Wrapper and these crappy services since.

[Ivan_Tellez]

@Greg_O

These services like to sync files as soon as they appear and sometimes they don’t check if a file is in use before they do so.

Why should they? Tose apps just check if the file has a lock or not, is up to the writing app to lock the file before writing so no other app can read a half saved file.

Curious, there are literrally Billions of files being readed and writed Monthly just by DropBox, But only xojo proyects are being corrupted… Sure, must be Dropbox.

@Greg_O

I honestly don’t know if you can tell if a file that you created and are currently writing to has been locked by another service, and if you can, what it would do to the performance, having to check for every little write.

File Locking has being part of any OS for decades. Is up to the writing App to use it properly.

[Sam_Rowlands]

Not just file locking.

They could use Atomic saving, so the data is written to the system temporary folder on that same drive, then the OS will replace the old file with the correctly written out updated file. Then the only problem would be one of these services overwriting with an older version.

I won’t hold my breath though…

[Sascha_S]

@Sam_Rowlands

Maybe that’s just me

And i still use it too

[Sam_Rowlands]

I wrote a newer, but never released version. As Xojo wants me to re-write it (and all my other apps), I plan to do as a learning experience in Swift.

[Arnaud_N]

@Greg_O

And I probably looked at it too, but seeing the problem and reproducing the issue is a little like looking at a car after an accident and being asked to figure out what caused the accident in the first place.

Especially when it’s a not-yet known accident type.

[Sascha_S]

@Ivan_Tellez

Curious, there are literrally Billions of files being readed and writed Monthly just by DropBox, But only xojo proyects are being corrupted… Sure, must be Dropbox.

That is not completely right. I’ve already seen references in a lot of apps that you shouldn’t save in Dropbox, OneDrive and the like. Or I had to activate an extra “Dropbox” & Co. mode in the app before it worked without errors.

[Jeff_Tullin]

@Sascha_S

had to activate an extra “Dropbox” & Co. mode

Which basically makes the app start creating in temp, then copying to Dropbox area later, as Sam was describing

[Thomas_ROBISSON]

@Ivan_Tellez

Curious, there are literrally Billions of files being readed and writed Monthly just by DropBox, But only xojo proyects are being corrupted… Sure, must be Dropbox.

I never used DropBox, but I received some emails from people who bought my sync application and wrote me they are happy with it and stopped to use DropBox because they encountered troubles.

I don’t know, but maybe Dropbox has problems with big file. If the big file is a photo or a video instead of a Xojo project, will people see if some pixels are not the same as the original?

[Greg_O]

@Thomas_ROBISSON

If the big file is a photo or a video instead of a Xojo project, will people see if some pixels are not the same as the original?

When I worked in prepress, we used to call these “zippers”. A single line (or part of a line) would get moved or the colors rotated (R > G, G > B, B > R).