Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2010-01

Damaged .ppu problem

8 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Nikolai Zhubr

Hello people,

I've discovered that (at least on win32) the compiler (2.2.2 and 2.4.0) refuse to overwrite an invalid PPU file. It just stops.

One typical case is when PPU creation had previously failed due to disk problems (e.g. out of room) or compilation abort, whatever, resulting in 0-size ppu file(s). In such case I have to find and manually delete the damaged ppu files, or otherwise compilation fails. This is somewhat inconvenient. I don't have a patch, sorry. Should I fill some bugreport?

Nikolai

Reply by email

Florian Klaempfl
to Nikolai Zhubr
Show quoted text 10 lines
Hello people, I've discovered that (at least on win32) the compiler (2.2.2 and 2.4.0) refuse to overwrite an invalid PPU file. It just stops. One typical case is when PPU creation had previously failed due to disk problems (e.g. out of room) or compilation abort, whatever, resulting in 0-size ppu file(s). In such case I have to find and manually delete the damaged ppu files, or otherwise compilation fails. This is somewhat inconvenient. I don't have a patch, sorry. Should I fill some bugreport?

I don't think that people will be happy if the compiler just deletes their ppus if it can't read it for any reason. The compiler cannot know if it can recreate the ppu when it deletes it.

Reply by email

peter green
to Florian Klaempfl
I don't think that people will be happy if the compiler just deletes their ppus if it can't read it for any reason. The compiler cannot know if it can recreate the ppu when it deletes it.

Can't it just be made to treat a damaged/unreadable ppu in the same way as an outdated or incompatible (afaict fpc already has ways to deal with ppus that are from the wrong compiler version or built with the wrong version of a unit they depend on) ppu?

Reply by email

Nikolai Zhubr
to Florian Klaempfl: I don't think that people will be happy if the compiler just deletes their ppus if it…

15.01.2010 0:01, Florian Klaempfl:

I don't think that people will be happy if the compiler just deletes their ppus if it can't read it for any reason. The compiler cannot know if it can recreate the ppu when it deletes it.

Well, when a user asks compiler to compile, doesn't it also mean "and whichever intermediate file(s) are wrong or missing, try to (re-)create them automatically"?

What's the point of being so carefull about unreadable PPUs? If a user have some very important PPUs s/he care about, then s/he could:

- set read-only file permissions for these PPUs,
- move source files away from these PPUs to avoid auto recompilation,
- make backups as necessary.

Nikolai

Reply by email

Florian Klaempfl
to Nikolai Zhubr
Show quoted text 10 lines
15.01.2010 0:01, Florian Klaempfl: > I don't think that people will be happy if the compiler just deletes > their ppus if it can't read it for any reason. The compiler cannot know > if it can recreate the ppu when it deletes it. Well, when a user asks compiler to compile, doesn't it also mean "and whichever intermediate file(s) are wrong or missing, try to (re-)create them automatically"? What's the point of being so carefull about unreadable PPUs?

Simply because it means that something really strange happened. Maybe it is only a wrong compiler version but it could be also a corrupted file system and then starting to delete files is really bad.

Reply by email

Nikolai Zhubr
to Florian Klaempfl

15.01.2010 10:50, Florian Klaempfl:

Show quoted text 5 lines
> What's the point of being so carefull about unreadable PPUs? Simply because it means that something really strange happened. Maybe it is only a wrong compiler version but it could be also a corrupted file system and then starting to delete files is really bad.

Hmm. I'd suppose pressing ctrl-C during compilation is not so strange and way more common than corrupted filesystems. And fpc is probably not an fschk replacement anyway :)

Ok, maybe some command-line option could be usefull to explicitely allow such PPU overwriting?

Nikolai

Reply by email

Michael Van Canneyt
to Nikolai Zhubr
Nikolai Zhubr wrote 13 lines
15.01.2010 10:50, Florian Klaempfl: >> What's the point of being so carefull about unreadable PPUs? > > Simply because it means that something really strange happened. Maybe it > is only a wrong compiler version but it could be also a corrupted file > system and then starting to delete files is really bad. Hmm. I'd suppose pressing ctrl-C during compilation is not so strange and way more common than corrupted filesystems. And fpc is probably not an fschk replacement anyway :) Ok, maybe some command-line option could be usefull to explicitely allow such PPU overwriting?

-B should do that.

Michael.

Reply by email

Nikolai Zhubr
to Michael Van Canneyt

15.01.2010 14:12, Michael Van Canneyt:

Show quoted text 5 lines
> > Ok, maybe some command-line option could be usefull to explicitely > allow such PPU overwriting? -B should do that.

It does not actually, I've just checked.
If I explicitely ask to compile the unit for which a damaged PPU file does exist then no problem - it compiles and replaces damaged PPU with a new one. However, in case of automatic recompilation of any file other than specified as an argument, compiler refuses to overwrite, and "-B" does not seem to help.

This is not a major issue, no. It is just somewhat unlogical, imho.

Nikolai

Michael.

Reply by email