browse compressed archives - now final!
Moderators: fgagnon, nikos, Site Mods
Re: browse compressed archives - now final!
which part of PM me don't you get...
Re: browse compressed archives - now final!
I am not good with some acronyms. LOL, I get, PM is meaningless to me (though I now understand it means private message).
I agree this has become a pointless debate. So consider it over. Nice picture, BTW (another acronym I know).
I agree this has become a pointless debate. So consider it over. Nice picture, BTW (another acronym I know).
- FrizzleFry
- Platinum Member
- Posts: 1241
- Joined: 2005 Oct 16, 19:09
Re: browse compressed archives - now final!
I noticed that 7zNSE does not like archives created by 7zip command line that include the full path including the drive letter (using -spf switch)... you get the typical error beep when you try to browse then... 7zNSE does work on archives with full paths but no drive letters (using -spf2 switch)... the 7Zip GUI opens them fine...
I do not use the full paths with drive letters option but I was messing with my backup script and noticed and tested the option.
I do not use the full paths with drive letters option but I was messing with my backup script and noticed and tested the option.
Re: browse compressed archives - now final!
which version of 7z are you using? my 9.20 doesn't understand this command line. Or to make things easier can you email to me a small 7z archive that shows the problem? Thanks
- FrizzleFry
- Platinum Member
- Posts: 1241
- Joined: 2005 Oct 16, 19:09
Re: browse compressed archives - now final!
I was using 7-Zip 9.38 when I posted and I'm now on 15.5... both versions support the -spf and -spf2 switches...
this is a sample command line...
D:\tools\7-Zip\7z.exe a -spf -t7z test.7z D:\tools\7-Zip\*
sent archive to support email...
Another problem with the current 7zNSE is that it locks files that you browse or attempt to browse... the ones that were successfully browsed are released after you browse another archive but the ones that fail to browse stay locked and cannot be deleted until you close/restart x2.
this is a sample command line...
D:\tools\7-Zip\7z.exe a -spf -t7z test.7z D:\tools\7-Zip\*
sent archive to support email...
Another problem with the current 7zNSE is that it locks files that you browse or attempt to browse... the ones that were successfully browsed are released after you browse another archive but the ones that fail to browse stay locked and cannot be deleted until you close/restart x2.
Re: browse compressed archives - now final!
Yeah, I can verify the second part - except, oddly, not for RAR5 types - they too "fail to browse" yet do not remain locked; they are the only exception I can find - all others do indeed pose a more imminent threat to national security. That said, it only applies to archives which resist browsing - I only see "locking" intermittently for kosher files, locking is not a constant (if it were, I'd be far more vocal).FrizzleFry wrote:the ones that were successfully browsed are released after you browse another archive but the ones that fail to browse stay locked and cannot be deleted until you close/restart x2...
Curiously, I have seen "super-locked" archives, which resist both a restart (process-level) of Windows Explorer and x2. The only way to unlock them is to wholly disassociate its extension via 7zNSE Config and then restart the PC itself, which is madness. Thankfully, these are very rare.
WinRAR also has the ability to store fully qualified paths (a GUI option, for convenience). Exactly why anyone would ever create such a thing (a very poor-man's installer?) is beyond me, but I can find no discernible pattern to their behaviour... sometimes they browse fine (they open a virtual folder of the drive-letter itself, and allow further browsing) - yet other times they are completely rejected and refuse 7zNSE altogether. Curiously, if two objects from differing absolute drive-paths are included in the same archive, the second one will not show up at all - it only virtualises the root of the first object and ignores the existence of the other.
- FrizzleFry
- Platinum Member
- Posts: 1241
- Joined: 2005 Oct 16, 19:09
Re: browse compressed archives - now final!
The archive locking thing reminds me of the "don't lock browsed folder" behavior, where the last folder from which something was launched gets locked... browsing an archive is basically a launch of the archive file... I wonder if they are related...
I don't know how intermittent locking browsed archives is, since I don't usually try to delete archives that I browse, but it seems that most times I try to delete one it is locked... but of course you remember the annoyances
I don't know how intermittent locking browsed archives is, since I don't usually try to delete archives that I browse, but it seems that most times I try to delete one it is locked... but of course you remember the annoyances
Re: browse compressed archives - now final!
No end of fun to be made with that one... Especially with Gallophiles on this anniversary of Waterloo...FrizzleFry wrote:...but of course you remember the annoyances
But yes, one can only empirically test these things so far... usually I rate it by creating an archive, "browsing it", then obliterating its short life before it can walk and talk and plan its own evil deeds, with/without intervening folder changes. Most often it seems to work fine, but occasionally it goes awry; certainly the latter for the "failed" types as you noted above.
I've never understood the "don't lock" thing anyway... would there ever be a time that I would actually want to lock a browsed folder? I can't think of one. Never mind that we're browsing virtual-folders here anyway, so it's above my pay-grade and may be completely unrelated to every-day reality anyway.
- FrizzleFry
- Platinum Member
- Posts: 1241
- Joined: 2005 Oct 16, 19:09
Re: browse compressed archives - now final!
locking the browsed folder sets it as the working folder for launched processes... that is good for people like me that like to double-click on scripts or other things to run them with that folder as the working folder... that is the default x2 behavior... for people that do not like that behavior there is the "don't lock browsed folder" option which only locks folders that stuff is launched from; however, that folder stays locked until you launch something from another folder which can be annoying (and memorable)
I never check "don't lock browsed folder" but occasionally since v3x I do get some folder locked as working folder and neither browsing to nor launching stuff from other folders clears that lock... I have to exit x2 to clear it... I am now wondering if the archive locking from 7zNSE is a related issue...
I never check "don't lock browsed folder" but occasionally since v3x I do get some folder locked as working folder and neither browsing to nor launching stuff from other folders clears that lock... I have to exit x2 to clear it... I am now wondering if the archive locking from 7zNSE is a related issue...
Re: browse compressed archives - now final!
Yeah, that's what I thought - in which case "lock" does not mean "lock" in the sense of folders being deletable. Two separate issues, I should think: the current working folder is just a colloquial abstraction (and something the OS uses as a placeholder, not a garrote), whereas a locked object is just that, a filesystem object marked as being explicitly process/thread safe.
It's not surprising that semantics break down when homographs gatecrash the party. Sometimes I really want to debug Nikos' brain before he labels an otherwise innocuous option - it would save us oompa-loompas an awful lot of paperwork in the long run. In this case I'm about 10 years too late, but a little mental reconditioning (read: frontal-labotomy) never hurt anyone who furiously ponders (squirrel-like) where he buried his stash of drachmae before the euro shrunk his banknotes.
It's not surprising that semantics break down when homographs gatecrash the party. Sometimes I really want to debug Nikos' brain before he labels an otherwise innocuous option - it would save us oompa-loompas an awful lot of paperwork in the long run. In this case I'm about 10 years too late, but a little mental reconditioning (read: frontal-labotomy) never hurt anyone who furiously ponders (squirrel-like) where he buried his stash of drachmae before the euro shrunk his banknotes.
Re: browse compressed archives - now final!
this mysterious locking doesn't have anything to do with xplorer2 "don't lock browsed folder". The shell extension folder when opened with xplorer2 somehow acquires locks also within explorer (!) that are magically released when you browse somewhere else. I must be doing something wrong inside the NSE code. Do you see such lockings when you browse with windows explorer too?
furhtermore this locking only occurs when you browse into a SUBfolder of the archive, if you keep it at the top level there is no lock
furhtermore this locking only occurs when you browse into a SUBfolder of the archive, if you keep it at the top level there is no lock
Re: browse compressed archives - now final!
Yes (tested via repeated observation below). Curiously, sometimes I am unable to browse back into a subfolder with explorer (nothing happens when clicking on it, even though it worked fine 30 seconds earlier), whereas x2 does not seem have a problem with this "re-browsing". Strange.nikos wrote:Do you see such lockings when you browse with windows explorer too?
Ooh, nice observation, Batman! That forces the issue indeed. That would also explain the annoyances I have when archives which are "searched" get locked, whereas single-level browsing of the same archive does not lock.nikos wrote:...this locking only occurs when you browse into a SUBfolder of the archive, if you keep it at the top level there is no lock
Re: browse compressed archives - now final!
coming back to the full paths in archives issue, it is a bit of a joke since at least 7z itself cannot extract the files properly, but creates local subfolders for the "filesystem" paths like C_ and N_. I think I can cover it but it looks like a waste of time!
Re: browse compressed archives - now final!
I don't know about 7Zip, but WinRAR extracts properly if one ticks the "extract to original location" box - I assume 7z has a similar option somewhere that you just didn't see. If one doesn't tick that box, then it sort of invents a funky relative path. End result is that they do work, but (again) the "why" of it escapes me. I would think outside of self-extracting archives, they would be extremely rare. However, they should at least be browsable.
That being said, I would suggest that sorting out the extraction from passworded archives would be a higher priority, since they are a far more common malady, and there's no visible sign as to why nothing happens, which is a little weird. I mean, if I hogtied and gagged all the prisoners I keep locked in my dungeon, they would at least struggle a bit and clank their chains in the throes of agony, so empirical signs of distress would be expected. Same theory applies to archives... at least in my twisted little brain.
That being said, I would suggest that sorting out the extraction from passworded archives would be a higher priority, since they are a far more common malady, and there's no visible sign as to why nothing happens, which is a little weird. I mean, if I hogtied and gagged all the prisoners I keep locked in my dungeon, they would at least struggle a bit and clank their chains in the throes of agony, so empirical signs of distress would be expected. Same theory applies to archives... at least in my twisted little brain.
Re: browse compressed archives - now final!
it is in the pipeline, already you hear a DING when a fully protected archive cannot be opened, and those weird ones that list contents but need password to extract will be a bit more obvious in this upcoming release