From mbmiller+l at gmail.com Sat Nov 2 10:13:56 2019 From: mbmiller+l at gmail.com (Mike Miller) Date: Sat, 2 Nov 2019 10:13:56 -0500 (CDT) Subject: [tclug-list] new location of chromium session files Message-ID: I just thought some of you might have the same problem I had with chromium browser moving to snap. This is the old location of session files: ~/.config/chromium/Default/Current\ Session This is the new location: ~/snap/chromium/current/.config/chromium/Default/Current\ Session But the old files are still in the old location, they just aren't being used. The "current" directory is a symlink to a directory named "920", but I assume that directory name can change. I sometimes use a perl one-liner to see all of the URLs in all of my tabs. Right now both of these work and give different answers: perl -nwle '$h{$_}++ for /http[[:print:]]+/g; END{print for sort keys %h;}' ~/snap/chromium/current/.config/chromium/Default/Current\ Session perl -nwle '$h{$_}++ for /http[[:print:]]+/g; END{print for sort keys %h;}' ~/.config/chromium/Default/Current\ Session I think the new snap chromium imported the old session, but it crashed when I started it, and then it lost all the old tabs. I had a lot of tabs open, but I don't think it should crash. I'll try copying the old files to see if I can make it work. Mike From tclug1 at whitleymott.net Sat Nov 2 10:39:05 2019 From: tclug1 at whitleymott.net (gregrwm) Date: Sat, 2 Nov 2019 10:39:05 -0500 Subject: [tclug-list] new location of chromium session files In-Reply-To: References: Message-ID: as in "aw, snap!"? now named after a propensity to fail mysteriously? On Sat, Nov 2, 2019 at 10:14 AM Mike Miller wrote: > I just thought some of you might have the same problem I had with chromium > browser moving to snap. This is the old location of session files: > > ~/.config/chromium/Default/Current\ Session > > This is the new location: > > ~/snap/chromium/current/.config/chromium/Default/Current\ Session > > But the old files are still in the old location, they just aren't being > used. The "current" directory is a symlink to a directory named "920", > but I assume that directory name can change. > > I sometimes use a perl one-liner to see all of the URLs in all of my tabs. > Right now both of these work and give different answers: > > perl -nwle '$h{$_}++ for /http[[:print:]]+/g; END{print for sort keys > %h;}' ~/snap/chromium/current/.config/chromium/Default/Current\ Session > > perl -nwle '$h{$_}++ for /http[[:print:]]+/g; END{print for sort keys > %h;}' ~/.config/chromium/Default/Current\ Session > > I think the new snap chromium imported the old session, but it crashed > when I started it, and then it lost all the old tabs. I had a lot of tabs > open, but I don't think it should crash. I'll try copying the old files > to see if I can make it work. > > Mike > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -- this concludes test 42 of big bang inflation dynamics. in the advent of an actual universe, further instructions will be provided. 000000000000000000000042 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tclug1 at whitleymott.net Tue Nov 12 19:25:26 2019 From: tclug1 at whitleymott.net (gregrwm) Date: Tue, 12 Nov 2019 19:25:26 -0600 Subject: [tclug-list] postmortem recovery utilities? Message-ID: a dear friend is bringing his laptop over tomorrow morning at 8:30am to see if we can find anything he had on it (in ubuntu) before it died and he took it to best buy for warranty service. they replaced the motherboard and installed windows 10. how thoughtful. for starters i'll look at the partitioning and see what might be there, but i rather expect to find windows 10 was told to take the whole disk for scratch. i've never used autopsy or anything like it so am entirely open to recommendations of what approaches would be most likely (even if rather unlikely) to bring joy for my friend. tia, greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From l at lhb.me Wed Nov 13 11:32:56 2019 From: l at lhb.me (LB) Date: Wed, 13 Nov 2019 11:32:56 -0600 Subject: [tclug-list] postmortem recovery utilities? In-Reply-To: References: Message-ID: <8f4fce77-817e-4fd9-a0fc-a6226fbf39c0@www.fastmail.com> I recommend Test Disk (https://www.cgsecurity.org/wiki/TestDisk) to recover files from overwritten partitions That sounds like a terrible situation though. It should definitely be used as a teaching moment about backups (or at least cloud storage) as well... In this day and age, data loss is almost inexcusable. On Tue, Nov 12, 2019, at 7:25 PM, gregrwm wrote: > a dear friend is bringing his laptop over tomorrow morning at 8:30am to see if we can find anything he had on it (in ubuntu) before it died and he took it to best buy for warranty service. they replaced the motherboard and installed windows 10. how thoughtful. for starters i'll look at the partitioning and see what might be there, but i rather expect to find windows 10 was told to take the whole disk for scratch. i've never used autopsy or anything like it so am entirely open to recommendations of what approaches would be most likely (even if rather unlikely) to bring joy for my friend. > tia, > greg > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaze0010 at umn.edu Wed Nov 13 12:12:46 2019 From: kaze0010 at umn.edu (Haudy Kazemi) Date: Wed, 13 Nov 2019 12:12:46 -0600 Subject: [tclug-list] postmortem recovery utilities? In-Reply-To: <8f4fce77-817e-4fd9-a0fc-a6226fbf39c0@www.fastmail.com> References: <8f4fce77-817e-4fd9-a0fc-a6226fbf39c0@www.fastmail.com> Message-ID: Also try PhotoRec https://www.cgsecurity.org/wiki/PhotoRec It uses file carving techniques to work with raw data (that has not been overwritten), even after a filesystem has been destroyed. This is just one tool of many that can do file carving. YMMV as file carving capabilities may vary between tools. More: https://www.cgsecurity.org/wiki/PhotoRec_Data_Carving Remember to avoid writing to any disk you intend to recover from. This also means to avoid booting and using the Windows installation on that drive. On Wed, Nov 13, 2019, 11:41 LB wrote: > I recommend Test Disk (https://www.cgsecurity.org/wiki/TestDisk) to > recover files from overwritten partitions > > That sounds like a terrible situation though. It should definitely be used > as a teaching moment about backups (or at least cloud storage) as well... > > In this day and age, data loss is almost inexcusable. > > On Tue, Nov 12, 2019, at 7:25 PM, gregrwm wrote: > > a dear friend is bringing his laptop over tomorrow morning at 8:30am to > see if we can find anything he had on it (in ubuntu) before it died and he > took it to best buy for warranty service. they replaced the motherboard > and installed windows 10. how thoughtful. for starters i'll look at the > partitioning and see what might be there, but i rather expect to find > windows 10 was told to take the whole disk for scratch. i've never used > autopsy or anything like it so am entirely open to recommendations of what > approaches would be most likely (even if rather unlikely) to bring joy for > my friend. > tia, > greg > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tclug1 at whitleymott.net Wed Nov 13 19:09:07 2019 From: tclug1 at whitleymott.net (gregrwm) Date: Wed, 13 Nov 2019 19:09:07 -0600 Subject: [tclug-list] EFI? (was postmortem recovery utilities?) Message-ID: thank you for the replies. surprise, his linux partitions are still there. but we're not out of the woods yet. tried chroot and grub-install, got "error: /usr/lib/grub/i386-pc/modinfo.sh doesn't exist." then downloaded boot-repair-disk and added it to my thumb drive of handy iso's. it quickly identified a sensible repair, but failed to perform it, saying "The current session is in Legacy mode. Please reboot the computer, and use this software in an EFI session. This will activate the function. For example, use a live-USB of Boot-Repair-Disk-64bit, after making sure your BIOS is set up to boot USB in EFI mode." so i'm guessing that means my friend's disc was setup as an EFI boot, meanwhile my handy thumb drive didn't boot in EFI mode, either for the live ubuntu i used to chroot and try grub-install, nor for the boot-repair-disk iso, and i'm guessing the bios in it's unquestionable wisdom is entirely inflexible, like if it's booted one way, it can't perform any operation on the other format, regardless that they are two separate discs, and grub, in it's unquestionable wisdom, uses the bios instead of direct i/o. have i got that about right? if so i guess i need to get another thumb drive for booting in EFI mode? or is there a way to tell grub to switch modes after grub boots up and before booting the iso? On Tue, Nov 12, 2019, 19:25 gregrwm wrote: > a dear friend is bringing his laptop over tomorrow morning at 8:30am to > see if we can find anything he had on it (in ubuntu) before it died and he > took it to best buy for warranty service. they replaced the motherboard > and installed windows 10. how thoughtful. for starters i'll look at the > partitioning and see what might be there, but i rather expect to find > windows 10 was told to take the whole disk for scratch. i've never used > autopsy or anything like it so am entirely open to recommendations of what > approaches would be most likely (even if rather unlikely) to bring joy for > my friend. > tia, > greg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chewie at wookimus.net Wed Nov 13 23:16:08 2019 From: chewie at wookimus.net (Chad Walstrom) Date: Wed, 13 Nov 2019 23:16:08 -0600 Subject: [tclug-list] postmortem recovery utilities? In-Reply-To: References: Message-ID: <8736erm413.fsf@wookimus.net> gregrwm writes: > [BestBuy] replaced the motherboard and installed windows 10. how > thoughtful. Other than taking it to Kroll Ontrack, I'm not sure you'll find much. It all depends upon the state of the drive prior and following re-installation. How large was it? What has he done with it since? Did they "defrag" the disk after re-installation, etc.? https://www.ontrack.com/services/data-recovery/eden-prairie/ Consider that windows dynamically allocates swap from available free space on the drive, you might only find random crap rather than meaningful data. I honestly believe it's a lost cause, and that the money that you might spend with Ontrack would be thrown away with few if any results. Hopefully, your friend made good backups. -- Chad Walstrom Blog: https://runswithd6s.gitlab.io/ Twitter: @runswithd6s Keybase: https://keybase.io/runswithd6s From tclug1 at whitleymott.net Fri Nov 15 11:46:46 2019 From: tclug1 at whitleymott.net (gregrwm) Date: Fri, 15 Nov 2019 11:46:46 -0600 Subject: [tclug-list] EFI? (was postmortem recovery utilities?) In-Reply-To: References: Message-ID: sheesh. no error from grub-install, but it still boots into windows. curious that i find these in /boot: vmlinux-4.13.0-28-generic vmlinux-4.13.0-36-generic vmlinux-4.13.0-36-generic.efi.signed vmlinux-4.13.0-37-generic vmlinux-4.13.0-37-generic.efi.signed vmlinux-4.13.0-38-generic vmlinux-4.13.0-38-generic.efi.signed vmlinux-4.13.0-39-generic vmlinux-4.13.0-39-generic.efi.signed vmlinux-4.13.0-41-generic vmlinux-4.13.0-41-generic.efi.signed vmlinux-4.13.0-43-generic vmlinux-4.13.0-43-generic.efi.signed vmlinux-4.13.0-45-generic vmlinux-4.13.0-45-generic.efi.signed vmlinux-4.15.0-29-generic vmlinux-4.15.0-30-generic vmlinux-4.15.0-32-generic ,,, vmlinux-4.15.0-62-generic vmlinux-4.15.0-64-generic vmlinux-4.15.0-65-generic curious that *.efi.signed doesn't exist for -28-, does for -36- thru -45-, but then no others. and curious that /boot/efi is empty. but, /boot/grub/x86_64-efi exists and is populated, and no other /boot/grub/* directory exists, so it looks like it was installed as efi. sort of. i don't have other EFI installations handy to inspect. do y'all? this is xenial. how does it look on yours? well this is what i did, in a terminal in boot-repair-disk: mkdir /mnt/boot-sav/sda7/mnt/a1 mount --bind /mnt/boot-sav/sd{,a7/mnt/}a1 mount -oro -tproc {,/mnt/boot-sav/sda7}/proc mount -oro --bind {,/mnt/boot-sav/sda7}/sys mount -oro,rbind {,/mnt/boot-sav/sda7}/dev mount -oro,bind {,/mnt/boot-sav/sda7}/lib/modules chroot /mnt/boot-sav/sda7 grub-install --uefi-secure-boot --target=x86_64-efi --no-nvram --efi-directory=/mnt/a1 /dev/sda it said something like: Installing for x86_64-efi platform. Installation finished. No error reported. but it still boots into windows. any ideas? On Wed, Nov 13, 2019 at 7:09 PM gregrwm wrote: > thank you for the replies. surprise, his linux partitions are still > there. but we're not out of the woods yet. tried chroot and > grub-install, got "error: /usr/lib/grub/i386-pc/modinfo.sh doesn't > exist." then downloaded boot-repair-disk and added it to my thumb drive > of handy iso's. it quickly identified a sensible repair, but failed to > perform it, saying "The current session is in Legacy mode. Please reboot > the computer, and use this software in an EFI session. This will activate > the function. For example, use a live-USB of Boot-Repair-Disk-64bit, after > making sure your BIOS is set up to boot USB in EFI mode." > > so i'm guessing that means my friend's disc was setup as an EFI boot, > meanwhile my handy thumb drive didn't boot in EFI mode, either for the live > ubuntu i used to chroot and try grub-install, nor for the boot-repair-disk > iso, and i'm guessing the bios in it's unquestionable wisdom is entirely > inflexible, like if it's booted one way, it can't perform any operation on > the other format, regardless that they are two separate discs, and grub, in > it's unquestionable wisdom, uses the bios instead of direct i/o. have i > got that about right? if so i guess i need to get another thumb drive for > booting in EFI mode? or is there a way to tell grub to switch modes after > grub boots up and before booting the iso? > > > On Tue, Nov 12, 2019, 19:25 gregrwm wrote: > >> a dear friend is bringing his laptop over tomorrow morning at 8:30am to >> see if we can find anything he had on it (in ubuntu) before it died and he >> took it to best buy for warranty service. they replaced the motherboard >> and installed windows 10. how thoughtful. for starters i'll look at the >> partitioning and see what might be there, but i rather expect to find >> windows 10 was told to take the whole disk for scratch. i've never used >> autopsy or anything like it so am entirely open to recommendations of what >> approaches would be most likely (even if rather unlikely) to bring joy for >> my friend. >> tia, >> greg >> > -- this concludes test 42 of big bang inflation dynamics. in the advent of an actual universe, further instructions will be provided. 000000000000000000000042 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tclug1 at whitleymott.net Fri Nov 15 16:38:38 2019 From: tclug1 at whitleymott.net (gregrwm) Date: Fri, 15 Nov 2019 16:38:38 -0600 Subject: [tclug-list] EFI? (was postmortem recovery utilities?) In-Reply-To: References: Message-ID: ok, did a bit more researching, then tried cp -b /mnt/boot-sav/sda1/EFI/{ubuntu/grub,Boot/boot}x64.efi still booted windows. so i similarly replaced EFI/{Windows/Boot,dell/SOS}/bootmg{r,fw}x64.efi while i don't recommend this solution, it now boots ubuntu. On Fri, Nov 15, 2019 at 11:46 AM gregrwm wrote: > sheesh. no error from grub-install, but it still boots into windows. > > curious that i find these in /boot: > vmlinux-4.13.0-28-generic > vmlinux-4.13.0-36-generic > vmlinux-4.13.0-36-generic.efi.signed > vmlinux-4.13.0-37-generic > vmlinux-4.13.0-37-generic.efi.signed > vmlinux-4.13.0-38-generic > vmlinux-4.13.0-38-generic.efi.signed > vmlinux-4.13.0-39-generic > vmlinux-4.13.0-39-generic.efi.signed > vmlinux-4.13.0-41-generic > vmlinux-4.13.0-41-generic.efi.signed > vmlinux-4.13.0-43-generic > vmlinux-4.13.0-43-generic.efi.signed > vmlinux-4.13.0-45-generic > vmlinux-4.13.0-45-generic.efi.signed > vmlinux-4.15.0-29-generic > vmlinux-4.15.0-30-generic > vmlinux-4.15.0-32-generic > ,,, > vmlinux-4.15.0-62-generic > vmlinux-4.15.0-64-generic > vmlinux-4.15.0-65-generic > > curious that *.efi.signed doesn't exist for -28-, does for -36- thru -45-, > but then no others. and curious that /boot/efi is empty. but, > /boot/grub/x86_64-efi exists and is populated, and no other /boot/grub/* > directory exists, so it looks like it was installed as efi. sort of. i > don't have other EFI installations handy to inspect. do y'all? this is > xenial. how does it look on yours? > > well this is what i did, in a terminal in boot-repair-disk: > mkdir /mnt/boot-sav/sda7/mnt/a1 > mount --bind /mnt/boot-sav/sd{,a7/mnt/}a1 > mount -oro -tproc {,/mnt/boot-sav/sda7}/proc > mount -oro --bind {,/mnt/boot-sav/sda7}/sys > mount -oro,rbind {,/mnt/boot-sav/sda7}/dev > mount -oro,bind {,/mnt/boot-sav/sda7}/lib/modules > chroot /mnt/boot-sav/sda7 > grub-install --uefi-secure-boot --target=x86_64-efi --no-nvram > --efi-directory=/mnt/a1 /dev/sda > > it said something like: > Installing for x86_64-efi platform. > Installation finished. No error reported. > > but it still boots into windows. any ideas? > > > On Wed, Nov 13, 2019 at 7:09 PM gregrwm wrote: > >> thank you for the replies. surprise, his linux partitions are still >> there. but we're not out of the woods yet. tried chroot and >> grub-install, got "error: /usr/lib/grub/i386-pc/modinfo.sh doesn't >> exist." then downloaded boot-repair-disk and added it to my thumb drive >> of handy iso's. it quickly identified a sensible repair, but failed to >> perform it, saying "The current session is in Legacy mode. Please reboot >> the computer, and use this software in an EFI session. This will activate >> the function. For example, use a live-USB of Boot-Repair-Disk-64bit, after >> making sure your BIOS is set up to boot USB in EFI mode." >> >> so i'm guessing that means my friend's disc was setup as an EFI boot, >> meanwhile my handy thumb drive didn't boot in EFI mode, either for the live >> ubuntu i used to chroot and try grub-install, nor for the boot-repair-disk >> iso, and i'm guessing the bios in it's unquestionable wisdom is entirely >> inflexible, like if it's booted one way, it can't perform any operation on >> the other format, regardless that they are two separate discs, and grub, in >> it's unquestionable wisdom, uses the bios instead of direct i/o. have i >> got that about right? if so i guess i need to get another thumb drive for >> booting in EFI mode? or is there a way to tell grub to switch modes after >> grub boots up and before booting the iso? >> >> >> On Tue, Nov 12, 2019, 19:25 gregrwm wrote: >> >>> a dear friend is bringing his laptop over tomorrow morning at 8:30am to >>> see if we can find anything he had on it (in ubuntu) before it died and he >>> took it to best buy for warranty service. they replaced the motherboard >>> and installed windows 10. how thoughtful. for starters i'll look at the >>> partitioning and see what might be there, but i rather expect to find >>> windows 10 was told to take the whole disk for scratch. i've never used >>> autopsy or anything like it so am entirely open to recommendations of what >>> approaches would be most likely (even if rather unlikely) to bring joy for >>> my friend. >>> tia, >>> greg >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From eng at pinenet.com Tue Nov 19 23:17:29 2019 From: eng at pinenet.com (Rick Engebretson) Date: Tue, 19 Nov 2019 23:17:29 -0600 Subject: [tclug-list] openSuse 15.1 Message-ID: I've had a little time to discover yet another step into the linux future. Installing opensuse 15.1 on the same PC with opensuse 42.3 revealed some changes. First, NetworkManager is now booted by default. It discovered the needed network driver automatically for my wired eth, and hooks right into the internet. Before, I had to use the Yast network set-up tool. I don't know if automatic network eth and wifi is smart, but I don't see anybody too worried about security anymore. Looking into the Yast "services manager" tool I then resolved other confusions. The buttons indicate "start" choices of "manually," or "on boot." Instead of the previous "enable" or "disable." Kind of an aha moment for me. Another capability is new desktops mentioned by TCLUG members. And a surprise is new kernel documentation in HTML. I don't know where to go with this, except I need a hardware upgrade. I looked at Intel NUCs and their "Clear Linux" but don't yet feel like getting naked on "the cloud." Simply put, I'm getting swept into the past, but I'm not dead yet and really like what might be the last chapter in my linux experience. From tclug1 at whitleymott.net Wed Nov 20 09:41:26 2019 From: tclug1 at whitleymott.net (gregrwm) Date: Wed, 20 Nov 2019 09:41:26 -0600 Subject: [tclug-list] zip opaque Message-ID: i have a .zip (actually a java archive) in which i need to replace a script. unzip -Z currently shows: >-rw---- 2.0 fat 1365952 b- defN 09-Jan-01 00:00 META-INF/com/google/android/update-binary >-rw-rw-r-- 3.0 unx 1221 tx defN 19-Nov-20 00:37 META-INF/com/google/android/updater-script what do i need to do so updater-script is "fat...b-" instead of "unx...tx"? when i try: >zip -r ../lineage-16.0-20191117-nightly-kltedv-signed.zip -k -b META-INF/com/google/android/updater-script i get: >zip error: Nothing to do! (../lineage-16.0-20191117-nightly-kltedv-signed.zip) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at lunn.ch Wed Nov 20 10:12:21 2019 From: andrew at lunn.ch (Andrew Lunn) Date: Wed, 20 Nov 2019 17:12:21 +0100 Subject: [tclug-list] zip opaque In-Reply-To: References: Message-ID: <20191120161221.GG19542@lunn.ch> On Wed, Nov 20, 2019 at 09:41:26AM -0600, gregrwm wrote: > i have a .zip (actually a java archive) in which i need to replace a script. > > unzip -Z currently shows: > >-rw----     2.0 fat  1365952 b- defN 09-Jan-01 00:00 META-INF/com/google/ > android/update-binary > >-rw-rw-r--  3.0 unx     1221 tx defN 19-Nov-20 00:37 META-INF/com/google/ > android/updater-script > > what do i need to do so updater-script is "fat...b-" instead of "unx...tx"? man zipinfo zipinfo has a number of modes, and its behavior can be rather difficult to fathom if one isn't familiar with Unix ls(1) (or even if one is). The default behavior is to list files in the following format: -rw-rws--- 1.9 unx 2802 t- defX 11-Aug-91 13:48 perms.2660 ... The second and third fields indicate that the file was zipped under Unix with version 1.9 of zip. Since it comes from Unix, the file permissions at the beginning of the line are printed in Unix format. The uncompressed file-size (2802 in this example) is the fourth field. So maybe you need Wine so you can run a DOS version of zip? Andrew From tclug1 at whitleymott.net Wed Nov 20 11:45:19 2019 From: tclug1 at whitleymott.net (gregrwm) Date: Wed, 20 Nov 2019 11:45:19 -0600 Subject: [tclug-list] zip opaque In-Reply-To: <20191120161221.GG19542@lunn.ch> References: <20191120161221.GG19542@lunn.ch> Message-ID: On Wed, Nov 20, 2019 at 10:46 AM Andrew Lunn wrote: > On Wed, Nov 20, 2019 at 09:41:26AM -0600, gregrwm wrote: > > i have a .zip (actually a java archive) in which i need to replace a > script. > > > > unzip -Z currently shows: > > >-rw---- 2.0 fat 1365952 b- defN 09-Jan-01 00:00 > META-INF/com/google/ > > android/update-binary > > >-rw-rw-r-- 3.0 unx 1221 tx defN 19-Nov-20 00:37 > META-INF/com/google/ > > android/updater-script > > > > what do i need to do so updater-script is "fat...b-" instead of > "unx...tx"? > > man zipinfo > > zipinfo has a number of modes, and its behavior can be rather > difficult to fathom if one isn't familiar with Unix ls(1) (or even > if one is). The default behavior is to list files in the following > format: > > -rw-rws--- 1.9 unx 2802 t- defX 11-Aug-91 13:48 perms.2660 > > ... > > The second and third fields indicate that the file was zipped under > Unix with version 1.9 of zip. Since it comes from Unix, the > file permissions at the beginning of the line are printed in Unix > format. The uncompressed file-size (2802 in this example) is > the fourth field. > > So maybe you need Wine so you can run a DOS version of zip? > thank you. as in much of life it seems the challenge is to ask the right question. what i really want is to get my phone working. recent builds of lineageos seem to need to have the first line of updater-script deleted. of course that's buried in a java archive (.zip). seemed easy enough, but the updater-script won't run now, and i don't really know why. so i'm wondering if i should even try to pursue that further, or try to find where to find older and working lineageos builds for my phone, or go looking for some other rom. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tclug1 at whitleymott.net Wed Nov 20 11:55:46 2019 From: tclug1 at whitleymott.net (gregrwm) Date: Wed, 20 Nov 2019 11:55:46 -0600 Subject: [tclug-list] zip opaque In-Reply-To: References: <20191120161221.GG19542@lunn.ch> Message-ID: On Wed, Nov 20, 2019 at 11:45 AM gregrwm wrote: > On Wed, Nov 20, 2019 at 10:46 AM Andrew Lunn wrote: > >> On Wed, Nov 20, 2019 at 09:41:26AM -0600, gregrwm wrote: >> > i have a .zip (actually a java archive) in which i need to replace a >> script. >> > >> > unzip -Z currently shows: >> > >-rw---- 2.0 fat 1365952 b- defN 09-Jan-01 00:00 >> META-INF/com/google/ >> > android/update-binary >> > >-rw-rw-r-- 3.0 unx 1221 tx defN 19-Nov-20 00:37 >> META-INF/com/google/ >> > android/updater-script >> > >> > what do i need to do so updater-script is "fat...b-" instead of >> "unx...tx"? >> >> man zipinfo >> >> zipinfo has a number of modes, and its behavior can be rather >> difficult to fathom if one isn't familiar with Unix ls(1) (or even >> if one is). The default behavior is to list files in the >> following format: >> >> -rw-rws--- 1.9 unx 2802 t- defX 11-Aug-91 13:48 perms.2660 >> >> ... >> >> The second and third fields indicate that the file was zipped >> under Unix with version 1.9 of zip. Since it comes from Unix, the >> file permissions at the beginning of the line are printed in Unix >> format. The uncompressed file-size (2802 in this example) is >> the fourth field. >> >> So maybe you need Wine so you can run a DOS version of zip? >> > > > thank you. as in much of life it seems the challenge is to ask the right > question. what i really want is to get my phone working. recent builds of > lineageos seem to need to have the first line of updater-script deleted. > of course that's buried in a java archive (.zip). seemed easy enough, but > the updater-script won't run now, and i don't really know why. so i'm > wondering if i should even try to pursue that further, or try to find where > to find older and working lineageos builds for my phone, or go looking for > some other rom. > perhaps the unx vs fat bit is unimportant, but the t- vs b- part probably is. what's baffling me is the zip manual claims that zip -r zipfile replacementfile will replace the file in the archive, but what happens is it says "nothing to do!" do i really have to go find a windows machine to get the file into the zip archive in binary format? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbmiller+l at gmail.com Sun Nov 24 20:17:28 2019 From: mbmiller+l at gmail.com (Mike Miller) Date: Sun, 24 Nov 2019 20:17:28 -0600 (CST) Subject: [tclug-list] new location of chromium session files In-Reply-To: References: Message-ID: On Sat, 2 Nov 2019, gregrwm wrote: > as in "aw, snap!"? now named after a propensity to fail mysteriously? It is less stable than it used to be. Searching for a cookie will usually crash the browser. That's super-annoying. Worse, it often does not recover the tabs as they were when it crashed. It never failed like that before they started using snap. I assume the change is because of something in chromium itself, and not in the package system, but I don't know. Mike