Lanchon

> I should make it clear, this is from a fork of FF ah ok... :-/ thanks!

...but don't give this too much thought, maybe. this is all a hack, over a hack, over... cause next when i've some time i'll try to argue that you should...

well CFR is an amazing wheel and i think u'll like the ideas in my post simply because they are interesting. i'm not saying you should rewrite CFR to use...

lol it took some time but here it is: https://github.com/leibnitz27/cfr/issues/186 if you decide to go that route, the info in this post becomes obsolete. if you don't, let me know...

sorry but big thumbs down to this change. never break unnecessarily. everybody will hate CFR for it. and '--version' is the standard tried and true way of doing this. i'm...

FYI: this link discusses the create/write/fsync/rename idiom: http://stackoverflow.com/questions/2333872/atomic-writing-to-file-with-python regarding this code: ``` f = open(tmpFile, 'w') f.write(text) # make sure that all data is on disk # see http://stackoverflow.com/questions/7433057/is-rename-without-fsync-safe f.flush()...

> Replaces the file with a copy > > all file system changes will be flushed to disk. these are implementation details and shouldn't be in the API. atomicity is...

and comparatively the save/replace solution has problems: 1. save() is unfit for all uses given that it is unsafe. it should be fixed or removed from the API. 2. replace()...

well, what can i say, my view is different. IMHO save() is broken because it causes a very high probability of loosing data, compared to any other saves the users...

> FYI - neither I nor the copperhead people like creating a general permission for signature spoofing. then i will never consider using your OS, FYI. > I might be...