Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file
On Wed, Nov 12, 2014 at 10:16 PM, to...@acm.org wrote: When opening a repo, if you select to overwrite all files, and a file to be updated happens to be read-only (R attrib set), the overwrite fails (it should) but if you then change the read-only to read-write, and try to see changes or try to revert the failed to update file with the repo version, nothing happens. FOSSIL somehow assumes that the checkout is in a correct state, even though it failed to overwrite, and the repo and check-out have different copies of the same file. That's apparently a bug (and thank you for the reproduction steps), but i've gotta ask: why on earth would have a read-only file under fossil's control (as opposed to having read-only generated files, which i do to keep me from accidentally editing the generated Makefiles instead of their input tempates)? Fossil doesn't store/set any attributes except +x (git doesn't support other attributes either (anymore), based on what i've read). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file
On Nov 13, 2014 7:20 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Nov 12, 2014 at 10:16 PM, to...@acm.org wrote: When opening a repo, if you select to overwrite all files, and a file to be updated happens to be read-only (R attrib set), the overwrite fails (it should) but if you then change the read-only to read-write, and try to see changes or try to revert the failed to update file with the repo version, nothing happens. FOSSIL somehow assumes that the checkout is in a correct state, even though it failed to overwrite, and the repo and check-out have different copies of the same file. That's apparently a bug (and thank you for the reproduction steps), but i've gotta ask: why on earth would have a read-only file under fossil's control (as opposed to having read-only generated files, which i do to keep me from accidentally editing the generated Makefiles instead of their input tempates)? I think I could imagine this (on Unix) if I'm developing as bch but testing as root (ie: I need elevated access to petrol something, maybe device access, binding to low sockets, etc). I wouldn't set something to ro on purpose, but could imagine accidentally changing ownership if (as root) I did a quick edit on a file... Regardless, interesting bug. Fossil doesn't store/set any attributes except +x (git doesn't support other attributes either (anymore), based on what i've read). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file
And I have to ask: Why do you have to ask? :) A problem is a problem regardless of how it became evident. No, I don’t keep read-only files under fossil control, obviously. Note I used the word ‘happens’ to be read-only. The read-only status was set to temporarily protect this one file from being overwritten along with all other changed files in the repo. So, rather than answer Y/N to whether to overwrite each file individually from the whole lot, I set the read-only flag to the one I didn’t want overwritten, and answered Yes to all... From: Stephan Beal Sent: Thursday, November 13, 2014 5:20 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file On Wed, Nov 12, 2014 at 10:16 PM, to...@acm.org wrote: When opening a repo, if you select to overwrite all files, and a file to be updated happens to be read-only (R attrib set), the overwrite fails (it should) but if you then change the read-only to read-write, and try to see changes or try to revert the failed to update file with the repo version, nothing happens. FOSSIL somehow assumes that the checkout is in a correct state, even though it failed to overwrite, and the repo and check-out have different copies of the same file. That's apparently a bug (and thank you for the reproduction steps), but i've gotta ask: why on earth would have a read-only file under fossil's control (as opposed to having read-only generated files, which i do to keep me from accidentally editing the generated Makefiles instead of their input tempates)? Fossil doesn't store/set any attributes except +x (git doesn't support other attributes either (anymore), based on what i've read). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file
On Thu, Nov 13, 2014 at 6:11 PM, to...@acm.org wrote: And I have to ask: Why do you have to ask? :) A problem is a problem regardless of how it became evident. Because i'm deciding whether it's worth investing time to fix what might be a non-problem (or a problem outside fossil's scope) ;). FWIW: i generally cringe when people respond to posts with why would you want to? and should have said why i was asking in my initial reply. No, I don’t keep read-only files under fossil control, obviously. Note I used the word ‘happens’ to be read-only. Fair enough. The read-only status was set to temporarily protect this one file from being overwritten along with all other changed files in the repo. So, rather than answer Y/N to whether to overwrite each file individually from the whole lot, I set the read-only flag to the one I didn’t want overwritten, and answered Yes to all... In any case, i agree it's a bug, but looking into it isn't high on my personal prio list because it's a really weird edge case with relatively little impact (as perceived by my limited world view). Could i convince you to post a ticket for it, including the bits from your first post, so we don't lose track of it? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file
I agree it’s not an everyday use case. I’ve been using fossil for nearly a year now, and it happened to me only once, just now. And, I’ve learned my lesson, so I’ll be more careful for this not to happen again. However, this is the kind of situation that it may not bite often at all but if it ever bites you, it might hurt a lot as you’ll end up losing possibly the only copy of a file, as committing won’t include this one, and closing the repo won’t warn you about uncommitted changes, and you may go home happy thinking everything is in order... until you blissfully overwrite it (this now no longer read-only file) next time you open the repo with the wrong version. From: Stephan Beal Sent: Thursday, November 13, 2014 7:19 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file On Thu, Nov 13, 2014 at 6:11 PM, to...@acm.org wrote: And I have to ask: Why do you have to ask? :) A problem is a problem regardless of how it became evident. Because i'm deciding whether it's worth investing time to fix what might be a non-problem (or a problem outside fossil's scope) ;). FWIW: i generally cringe when people respond to posts with why would you want to? and should have said why i was asking in my initial reply. No, I don’t keep read-only files under fossil control, obviously. Note I used the word ‘happens’ to be read-only. Fair enough. The read-only status was set to temporarily protect this one file from being overwritten along with all other changed files in the repo. So, rather than answer Y/N to whether to overwrite each file individually from the whole lot, I set the read-only flag to the one I didn’t want overwritten, and answered Yes to all... In any case, i agree it's a bug, but looking into it isn't high on my personal prio list because it's a really weird edge case with relatively little impact (as perceived by my limited world view). Could i convince you to post a ticket for it, including the bits from your first post, so we don't lose track of it? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file
(This was seen on a Windows 7 machine) When opening a repo, if you select to overwrite all files, and a file to be updated happens to be read-only (R attrib set), the overwrite fails (it should) but if you then change the read-only to read-write, and try to see changes or try to revert the failed to update file with the repo version, nothing happens. FOSSIL somehow assumes that the checkout is in a correct state, even though it failed to overwrite, and the repo and check-out have different copies of the same file. Here’s the test batch file I ran which shows the problem: @echo off echo Reproduce fossil issue with read-only overwrite failure consequences echo (where f = fossil) f ver -v f new sample.fossil md xxx dir xxx\aaa cd xxx f o ..\sample.fossil f add aaa f com -m Initial f close echo Make some changes to our file dir ../s aaa attrib +r aaa echo Answer Y or A(ll) f o ..\sample.fossil echo Failed to update. Let's remove the read-only status, and see... attrib -r aaa f cha f rev f com echo Nothing shown here. But, if we close and re-open the repo. f close echo Answer N f o ..\sample.fossil f cha echo Obviously, there are changes!!! -- OUTPUT -- Reproduce fossil issue with read-only overwrite failure consequences (where f = fossil) This is fossil version 1.30 [b9a1beda9e] 2014-10-25 01:01:31 UTC Compiled on Oct 25 2014 19:30:07 using msc-18.00 (32-bit) SQLite 3.8.7 2014-10-17 11:24:17 e4ab094f8a Schema version 2011-04-25 19:50 zlib 1.2.8, loaded 1.2.8 SSL (OpenSSL 1.0.1j 15 Oct 2014) project-id: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7 server-id: 2f3a9fff39ebc03e8d9879929afa6075b8ee766f admin-user: Tony (initial password is db3f67) project-name: unnamed repository: C:/temp/xxx/..\sample.fossil local-root: C:/temp/xxx/ config-db:C:/Users/Tony/AppData/Local/_fossil project-code: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7 checkins: 0 ADDED aaa New_Version: e2507b54298d9a57da83578667dc510861fed766 Make some changes to our file Answer Y or A(ll) overwrite C:/temp/xxx/aaa (a=always/y/N)? y aaa unable to open file C:/temp/xxx/aaa for writing Failed to update. Let's remove the read-only status, and see... nothing has changed; use --allow-empty to override Nothing shown here. But, if we close and re-open the repo. Answer N overwrite C:/temp/xxx/aaa (a=always/y/N)? WARNING: manifest checksum does not agree with disk project-name: unnamed repository: C:/temp/xxx/..\sample.fossil local-root: C:/temp/xxx/ config-db:C:/Users/Tony/AppData/Local/_fossil project-code: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7 checkout: e2507b54298d9a57da83578667dc510861fed766 2014-11-12 21:12:17 UTC leaf: open tags: trunk comment: Initial (user: Tony) checkins: 1 EDITED aaa Obviously, there are changes!!! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file
[Default] On Wed, 12 Nov 2014 23:16:34 +0200, to...@acm.org wrote: (This was seen on a Windows 7 machine) When opening a repo, if you select to overwrite all files, and a file to be updated happens to be read-only (R attrib set), the overwrite fails (it should) but if you then change the read-only to read-write, and try to see changes or try to revert the failed to update file with the repo version, nothing happens. FOSSIL somehow assumes that the checkout is in a correct state, even though it failed to overwrite, and the repo and check-out have different copies of the same file. What are your settings for mtime-changes and repo-cksum ? -- Regards, Cordialement, Groet, Kees Nuyt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
