Re: ghost files
On Sun, Aug 7, 2011 at 3:08 AM, deeptec...@gmail.com wrote: > as of recent times, some git rebase operations fail unexpectedly with > an error: "cannot create .git/index.lock: file exists". an > investigation session was something like the following: > $ ls -l .git > the index.lock file is not in the shown list. > $ ls -l .git/index.lock > the file is listed! it's a regular file, its size is ~60KiB. > $ cat .git/index.lock > some file content is shown. > $ mv .git/index.lock .git/someplace > moving fails with: index.lock: file does not exist. > $ ee .git/index.lock > some file content is shown, which i edit and save. then the > .git/index.lock file really disappears (cat, direct ls, ee, mv, etc. > do not find the file), and the content i put in the .git/index.lock > file via ee is now in .git/index. > > H$X!111 > > i still have some git rebase operations (which are notably > disk-active) fail from time to time with "impossible" reasons (for > example: something like "cherry picking failed", or something like > "cannot move git-rebase-new to git-rebase-todo: file does not exist"). > > i'd note that the hard drive is kind of old (>7 years), and i recently > had the power cut during port build operations twice, although the > (UFS) filesystem is fsck-clean. > > has anyone experienced anything like this? > what is the possibility of a filesystem/kernel bug or fsck bug? Do not start supposing that this is a filesystem/kernel bug so early. I have seen similar mysterious messages @work, with Git servers running on Linux, so I'm inclined to believe that it is a software issue. -- "The flames are all long gone, but the pain lingers on" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
On 08/08/11 10:21, C. P. Ghost wrote: On Mon, Aug 8, 2011 at 2:51 AM, Garrett Cooper wrote: On Sun, Aug 7, 2011 at 2:48 PM, Super Biscuit wrote: I suggest sprinkling holy water on your computer and then hitting a bong. Who you gonna call :P? -Garrett (I couldn't resist) http://www.gnu.org/fun/jokes/vaxorcist.html -cpghost. Try 'fsck -fy' in single user, then 'fsck -fy ' in reverse of mounting sequence. I would also suggest moving your files off this disk. For what it's worth, on my laptop with a terrible battery, GJournal + UFS behaves very nicely with random frequent shutdowns (Lenovo battery :(). At least you are not seeing the red screen of satanic possession I saw on an HP box with a borked MBR. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
On Mon, Aug 8, 2011 at 2:51 AM, Garrett Cooper wrote: > On Sun, Aug 7, 2011 at 2:48 PM, Super Biscuit wrote: >> I suggest sprinkling holy water on your computer and then hitting a bong. > > Who you gonna call :P? > -Garrett (I couldn't resist) http://www.gnu.org/fun/jokes/vaxorcist.html -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
On Mon, Aug 8, 2011 at 12:57 AM, Doug Barton wrote: > On 08/06/2011 23:08, deeptec...@gmail.com wrote: >> i'd note that the hard drive is kind of old (>7 years), and i recently >> had the power cut during port build operations twice, although the >> (UFS) filesystem is fsck-clean. > > Have you actually booted single user and run 'fsck -y'? That should > probably be your next step. yes i have already done that. but just for show i double-checked again (single user mode, fsck -y), and the filesystem was reported to be clean. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
On Sun, Aug 7, 2011 at 2:48 PM, Super Biscuit wrote: > I suggest sprinkling holy water on your computer and then hitting a bong. Who you gonna call :P? -Garrett (I couldn't resist) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
On 08/06/2011 23:08, deeptec...@gmail.com wrote: > i'd note that the hard drive is kind of old (>7 years), and i recently > had the power cut during port build operations twice, although the > (UFS) filesystem is fsck-clean. Have you actually booted single user and run 'fsck -y'? That should probably be your next step. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
I suggest sprinkling holy water on your computer and then hitting a bong. --- On Sun, 8/7/11, deeptec...@gmail.com wrote: From: deeptec...@gmail.com Subject: ghost files To: freebsd-current@freebsd.org Date: Sunday, August 7, 2011, 6:08 AM as of recent times, some git rebase operations fail unexpectedly with an error: "cannot create .git/index.lock: file exists". an investigation session was something like the following: $ ls -l .git the index.lock file is not in the shown list. $ ls -l .git/index.lock the file is listed! it's a regular file, its size is ~60KiB. $ cat .git/index.lock some file content is shown. $ mv .git/index.lock .git/someplace moving fails with: index.lock: file does not exist. $ ee .git/index.lock some file content is shown, which i edit and save. then the .git/index.lock file really disappears (cat, direct ls, ee, mv, etc. do not find the file), and the content i put in the .git/index.lock file via ee is now in .git/index. H$X!111 i still have some git rebase operations (which are notably disk-active) fail from time to time with "impossible" reasons (for example: something like "cherry picking failed", or something like "cannot move git-rebase-new to git-rebase-todo: file does not exist"). i'd note that the hard drive is kind of old (>7 years), and i recently had the power cut during port build operations twice, although the (UFS) filesystem is fsck-clean. has anyone experienced anything like this? what is the possibility of a filesystem/kernel bug or fsck bug? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ghost files
as of recent times, some git rebase operations fail unexpectedly with an error: "cannot create .git/index.lock: file exists". an investigation session was something like the following: $ ls -l .git the index.lock file is not in the shown list. $ ls -l .git/index.lock the file is listed! it's a regular file, its size is ~60KiB. $ cat .git/index.lock some file content is shown. $ mv .git/index.lock .git/someplace moving fails with: index.lock: file does not exist. $ ee .git/index.lock some file content is shown, which i edit and save. then the .git/index.lock file really disappears (cat, direct ls, ee, mv, etc. do not find the file), and the content i put in the .git/index.lock file via ee is now in .git/index. H$X!111 i still have some git rebase operations (which are notably disk-active) fail from time to time with "impossible" reasons (for example: something like "cherry picking failed", or something like "cannot move git-rebase-new to git-rebase-todo: file does not exist"). i'd note that the hard drive is kind of old (>7 years), and i recently had the power cut during port build operations twice, although the (UFS) filesystem is fsck-clean. has anyone experienced anything like this? what is the possibility of a filesystem/kernel bug or fsck bug? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
