Full path to the file/folder inside an archive

[[Yustas.NeO]]

Is it possible to get the full path to the file/folder inside an archive ("%Z %P%N")? Like it "cm_CopyFullNamesToClip" does?


cm_CopyFullNamesToClip: C:\Test archive\1.ZIP\2\3\4\name.ext
%Z %P%N: C:\Test archive\1.ZIP\2\3\4\2\3\4\name.ext

Inside the archive "%N" ("%M") must be "name.ext" not "2\3\4\name.ext"


Inplace rename of the file inside an archive could stay "2\3\4\name.ext"...

[karlchen]

Hello, [Yustas.NeO].

Have you tried what the results are if you use the various cm_CopyNamesToClip commands, which can be found inside the file totalcmd.inc e.g., when you apply them inside an archive?

There is an archive here named Lucid_thunderbird.7z. It holds the current backup of the Thunderbird user profile.
Inside the archive there is .e.g the file named global-messages-db.sqlite.
Navigating to this filename inside the archive and executing cm_CopyFullNamesToClip yields this string

Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\global-messages-db.sqlite

So, the answer is: yes, the various cm_CopyNamesToClip commands work inside archives as well. You may have to find out which of the commands produces the result which you need.

The T.C. internal variables %P, %N, %M etc are a different story.

Cheers,
Karl

[[Yustas.NeO]]

I apologize if I poorly explained. I mean exactly intenal variables! F.e. I have a graphics viewer that works with archives. I would like to open photos using this viewer directly from the archives rather than the temporary folder of the TC.. So here is the question: how to send the full path of the foto into this viewer?

[karlchen]

Hello, [Yustas.NeO].

I love questions which force me to try an existing T.C. functionality which I had ignored for years.

There is my standard editor button:

Code: Select all

Command: [%COMMANDER_PATH%\..\Notepad2\Notepad2.exe]
Parameters:  [? %P%N]

This works fine for any text file outside and archive. If I use it on a file inside an archive, then it will yield the error message:

This function cannot be used with packed files!

If I change the button definition to be

Code: Select all

Command: [%COMMANDER_PATH%\..\Notepad2\Notepad2.exe]
Parameters:  [? %P%N %Z]

and apply it to the file pref.js inside the archive I mentioned in my previous post, a dialogue box pops up asking me whether I really want to edit this file:

Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\qvtzwvlj.default\prefs.js

This seems to suggest that the internal variables %P and %N work for files in archives as well, provided you add the pseudo variable %Z somewhere to the parameter field.

Yet, in the case of the editor Notepad2 this is of no use, because in order to allow editing the file pref.js, T.C. will extract it from the archive and pass this fully qualified filename to Notepad2: "C:\users\agnkhe\Temp\_tc\qvtzwvlj.default\prefs.js".

Launching Notepad2 and passing the name that "%P%N %Z" returns, i.e. "Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\qvtzwvlj.default\prefs.js" will result in the following Notepad2 dialogue:

"Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\qvtzwvlj.default\prefs.js" not found.
Would you like to create this file?

Conclusion:
Using "%P%N %Z" in a button parameter field and applying the button to a file in an archive will return the same path as applying cm_CopyFullNamesToClip.
Yet, it depends on the programme which you pass this fully qualified name whether it will be able to perform any reasonable action with this name.
Obviously a text editor will not be able to edit a file in an archive directly.

"%T%M %" in a button parameter field and applying the button to a file in an archive will return the correct pathname from the target panel.

Inside the archive "%N" ("%M") must be "name.ext" not "2\3\4\name.ext"

"%N" and "%M" always hold the filename.ext without the pathname. It is "%P" and "%T" which return the pathnames.

Kind regards,
Karl

[[Yustas.NeO]]

Conclusion:
Using "%P%N %Z" in a button parameter field and applying the button to a file in an archive will return the same path as applying cm_CopyFullNamesToClip.

It will not!

In your case "%P%N %Z" returns "qvtzwvlj.default\" twice.
I guess the full path to your file "prefs.js" is not "Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\qvtzwvlj.default\prefs.js" but "Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\prefs.js", isn't it?


P.S.
"?%Z %P --- %N" will return "C:\Test archive\1.ZIP\2\3\4\ --- 2\3\4\name.ext" instead of "C:\Test archive\1.ZIP\2\3\4\ --- name.ext"

[nsp]

"?%Z %P --- %N" will return "C:\Test archive\1.ZIP\2\3\4\ --- 2\3\4\name.ext" instead of "C:\Test archive\1.ZIP\2\3\4\ --- name.ext"

If it is like this you can assume that it is a bug with %N or %P

[karlchen]

Hello, [Yustas.NeO].

You are right. I had not noticed that the folder name qvtzwvlj.default appeared twice inside the name. and if I had read your initial post in this thread carefully enough I would have known from the start.
The fully qualified filename of pref.js is

Code: Select all

Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\prefs.js

(cm_CopyFullNamesToClip gets it right)

Now at last, I understand your initial post:
If you use %P on a file inside an archive, the returned path name will be correct. It will return the full pathname minus the filename.ext.
If you use %N on a file inside an archive, %N will not only return the filename including the extension, but it will prefix the relative foldernames which have been saved in the archive together with the filename.
This is why in my example the foldername qvtzwvlj.default appears twice.

Admitted, the combination %P%N if applied to a file inside an archive does not give the correct path. (By the way, the using the combination %T%M you can reproduce the same effect.)
Yet, even if it did, what could you do with this path?
Can you pass it to any programme as a commandline argument and that programme will be able to perform any action on the file? I doubt so, because the file is packed inside the archive. Before you can do anything with it you have to extract it temporarily and repack it afterwards (if the file has been modified).

So this flaw seems to be more academical than of practical relevance. - Or can someone enlighten me and give an example where the pathname %P%N pointing to a file inside an archive will be of practical use?

The reason why %N if applied to a file inside an archive will return the filename.ext plus the prefixed relative pathnames provided they have been stored inside the archive may be this:
No real folder structure is stored inside an archive.
Instead the filenames are stored with their releative pathnames inside the archive.
Use a hexviewer to verify. By the way, this can be verified more easily when inspecting .ZIP archives than when inspecting .7z archives.

Karl

[[Yustas.NeO]]

(By the way, the using the combination %T%M you can reproduce the same effect.)

Yes. I wrote about it in my first post.

Can you pass it to any programme as a commandline argument and that programme will be able to perform any action on the file? I doubt so, because the file is packed inside the archive. Before you can do anything with it you have to extract it temporarily and repack it afterwards (if the file has been modified).

Or can someone enlighten me and give an example where the pathname %P%N pointing to a file inside an archive will be of practical use?

About this i wrote in my second post
I've got graphics viewer that could work with archives. No need to extract files with TC. Also with this viewer i could navigate through the file structure of archives. Viewer do not edit files, so there is no need to repack files.
More examples? I use compare-tool that could compare file structure of archives and files inside archives.

The reason why %N if applied to a file inside an archive will return the filename.ext plus the prefixed relative pathnames provided they have been stored inside the archive is that no real folder structure is stored inside an archive. Instead the filenames are stored with their releative pathnames inside the archive.

However, the "cm_CopyFullNamesToClip" returns without any prefixed relative pathnames?

[petermad]

Try %P%n - it does not include the path inside the archive.

Another interesting thing if you use %p in stead of %P then the name of the acrhive file is left out.


Using %Z%P%n
Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\prefs.js
as expected.

Using %Z%P%N
Z:\home\karl\Downloads\Thunderbird\Lucid_thunderbird.7z\qvtzwvlj.default\qvtzwvlj.default\prefs.js
notice double "qvtzwvlj.default" part.

Using %Z%p%n
Z\home\karl\DOWNLO~1\THUNDE~1\qvtzwvlj.default\prefs.js
notice missing "Lucid_thunderbird.7z" part.

Using %Z%p%N
Z:\home\karl\DOWNLO~1\THUNDE~1\qvtzwvlj.default\qvtzwvlj.default\prefs.js
notice missing "Lucid_thunderbird.7z" part AND double "qvtzwvlj.default" part.


I would definately say that it is a bug for %N and %p inside archives (%n and %P works as expected).

I have reported this as a bug here: http://www.ghisler.ch/board/viewtopic.php?p=244051#244051

[[Yustas.NeO]]

Try %P%n - it does not include the path inside the archive.

"It isn't bug, it is feature" ))
It's suits me! Thanks!

[karlchen]

Hello, [Yustas.NeO].

By now, even I have realized that the internal variables %P, %N, %T, %M etc do not work consistently and correctly when applied to objects inside archives.

You wrote that your graphics viewer can handle archives internally, i.e. extract image files from archives for viewing purposes. May we learn the name of this graphics viewer? Or is it a cosmic top secret product?

The reason for asking simply is:

I wonder whether the misbehaviour which has been reported and reproduced really has got high relevance in everyday life.

Except for the graphics viewer which you mentioned, are there really any other use cases for %P, %N, %T, %M etc inside archives?

The question is not whether the behaviour is inconsistent and incorrect, but how much does it affect us? Do we really need a fix? Do we need a fix urgently? Or do we we just want a fix because the T.C. helpfile claims %P, %N, %T, %M can be used on objects inside archives, too?

So far, [Yustas.NeO], you seem to be the only one who has got any practical use for %P, %N, %T, %M inside archives. Is this really so?

Someone must have requested this feature in the past. Those people must have had a need for it. Where are these people? Should not at least some of them join this thread and explain what they would like to do, but cannot, because it does not work the way helpfile explains?

OK, enough, I am repeating myself.

Cheers,
Karl

[petermad]

"It isn't bug, it is feature

I only consider the behaviour of %p and %N buggy inside archives. %P and %n behaves as expected.

[karlchen]

Hello, Petermad. Hello, [Yustas.NeO].

Has it ever occurred to us that the different behaviour of %N vs %n applied to files inside archives might be by design, to cover two different use cases and that the explanation is simply absent from the helpfile?

In case the programme that you use can handle the fully qualified pathname to the file inside the archive, then you will use %P%n. I.e. %n used inside an archive will extract the pure filename (filename.ext) and strip any prefixed relative pathname stored inside the archive, because %P returns the complete path.

On the other hand, there may be cases where you do not need the path to the archive file at all, but only the filename as it has been stored inside the archive, i.e. with the relative pathname prefixed. In this case, you will simply use %N. (Just think of what <shift><f6> does when applied on a filename inside an archive)

Something similar might be true for %P and %p. They might by design cover two different use cases.

If this is true, then the helpfile should explain so.

The most funny thing about all these questions, however, is this: %Z seems to have been added in Total Commander 7.50. So for the past 2.5 years nobody noticed the behaviour of %P, %p, %N, %n when used in conjunction with %Z?

Kind regards,
Karl

[petermad]

2karlchen
See answer in http://www.ghisler.ch/board/viewtopic.php?p=244051#244051

[[Yustas.NeO]]

More tests:
The problem is not only with archives... (may be the topicname should be renamed?)


ARCHIVES
C:\Program Files\Total Commander\test\long foldername\long archivename.ZIP\1\long foldername in archive\3\long filename 1.extension

%P=C:\Program Files\Total Commander\test\long foldername\long archivename.ZIP\1\long foldername in archive\3\
%p=C:\PROGRA~1\TOTALC~1\test\LONGFO~1\1\long foldername in archive\3\ missing "long archivename.ZIP"
%N="1\long foldername in archive\3\long filename 1.extension"
%n=long filename 1.extension
%S="1\long foldername in archive\3\long filename 1.extension"
%s="1\long foldername in archive\3\long filename 1.extension"
%O=1\long foldername in archive\3\long filename 1
%o=long filename 1 (wrong but probably is not critical for archives)
%E=extension
%e=extension (wrong but probably is not critical for archives)

%T=C:\Program Files\Total Commander\test\long foldername\long archivename.ZIP\1\long foldername in archive\3\
%t=C:\PROGRA~1\TOTALC~1\test\LONGFO~1\
%M=1\long foldername in archive\3\long filename 2.extension
%m=1\long foldername in archive\3\long filename 2.extension
%R="1\long foldername in archive\3\long filename 1.extension"
%r="1\long foldername in archive\3\long filename 1.extension"



SIMPLE (right data)
C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip

%P=C:\Program Files\Total Commander\test\long foldername\
%p=C:\PROGRA~1\TOTALC~1\test\LONGFO~1\
%N="long archivename.ZIPzip"
%n=LONGAR~2.ZIP
%S="long archivename.ZIPzip"
%s=LONGAR~2.ZIP
%O=long archivename
%o=LONGAR~2
%E=ZIPzip
%e=ZIP

%T=C:\Program Files\Total Commander\test\long foldername\
%t=C:\PROGRA~1\TOTALC~1\test\LONGFO~1\
%M=long archivename.ZIPzip
%m=LONGAR~2.ZIP
%R="long archivename.ZIPzip"
%r="long archivename.ZIPzip"


SEARCH RESULTS
C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip
search in C:\Program Files\Total Commander\test\

%P=
%p=C:\PROGRA~1\TOTALC~1\test\LONGFO~1\
%N="C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip"
%n=long archivename.ZIPzip
%S="C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip"
%s="C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip"
%O=C:\Program Files\Total Commander\test\long foldername\long archivename
%o=long archivename
%E=ZIPzip
%e=ZIPzip

%T=
%t=
%M=C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip
%m=C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip
%R="C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip"
%r="C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip"


BRANCH VIEW
C:\Program Files\Total Commander\test\long foldername\long archivename.ZIPzip
branch in C:\Program Files\Total Commander\test\

%P=C:\Program Files\Total Commander\test\
%p=C:\PROGRA~1\TOTALC~1\test\LONGFO~1\
%N="long foldername\long archivename.ZIPzip"
%n=long archivename.ZIPzip
%S="long foldername\long archivename.ZIPzip"
%s="long foldername\long archivename.ZIPzip"
%O=long foldername\long archivename
%o=long archivename
%E=ZIPzip
%e=ZIPzip

%T=C:\Program Files\Total Commander\test\
%t=C:\PROGRA~1\TOTALC~1\test\
%M=long foldername\long archivename.ZIPzip
%m=long foldername\long archivename.ZIPzip
%R="long foldername\long archivename.ZIPzip"
%r="long foldername\long archivename.ZIPzip"