Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

p7zip 9.20.1b "testing" (Users)

posted by Rugxulo Homepage, Usono, 06.09.2012, 23:21

> > TODO:
> > ...
>
> = nit #1). Updating still tries using LFN-only blah.7z.tmp, which is annoying in SFN.
> I'm too tired right now to fix that (not that I know where it is
> exactly either). Workaround: "ren blah.7z blah", "7za d -r blah.
> sources\*.c", "ren blah *.7z".

Actually, it seems to assume .7z type by default, so if you want to "update" ('u' command) or "delete" ('d' command) in a .ZIP or .TAR, you have to also use "-ttar" or "-tzip", then it'll work for them too (as mentioned above, in SFN).

> * BUG: (worst, IMHO) "7za a -sfx dumbname somedir" doesn't work except on
> same drive as 7zcon.sfx (similarly "p7zip l c:\tmp\471*.zip" fails from
> atop G:\ RAM drive)
> = solution??: dunno ... something kludged up in argv[] ?? perhaps drive
> prefix is being deleted already? (needs further study)

Actually, when curdir is on C:, it works okay doing "7za l g:\somedir\myfile.tbz". It's just when sitting atop G: that it for some reason doesn't work reading from C:. (Verified in Khusraw's also.) Apparently a good workaround is "7za l c:c:\somedir\blah.tbz". So I guess the POSIX port is removing the drive name (or maybe only when prefix is "c:") explicitly somewhere.

I was also worried that it wouldn't work without a C:\TMP directory, but renaming mine didn't show any obvious errors in light testing. There is at least one place where it's hardcoded, but I didn't look too closely, so I didn't mess with it (yet).

Just FYI.

 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum