7-Zip

Let's assume we have (in the current directory) folder1\file1 and folder1\folder2\file2.

The command line is: 7za a foo folder1

This results in foo.7z containing both folder1\file1 and folder1\folder2\file2. Why is folder2 included?

According to Help, the recursion is disabled by default (by the way, the switch -r- won't prevent the inclusion of folder2 into the archive, too).

Thanks,
-- Shmuel

When you call "Copy" command on "folder1" in Explorer, it copies all subfolders also. 7-Zip does it same way.

I'm trying to instruct 7-Zip to include files and directories specified in a list file into the archive. I was (mistakenly) thinking that if the list contained a line "folder1", then this line wouldn't pull its entire contents in, but only the folder itself.

The question is: how one can specify an *arbitrary* set of files and folders (both empty and non-empty ones) to be included into the archive (via a list file)?

Thanks,
Shmuel

Try using -x!*\* to stop recursion on a folder
Im not sure if its just me but there does seem to be a bug in -r switch
Based on the help file using c:\temp\* should not recurse folders in c:\temp because the default switch is -r- ( which = no recurse for wildcards)
but it still recurses.

Show some example of your task.

My script generates a simple list of folders and files to be included into the target archive. Note the word "simple", it means: no wildcards, neither explicit nor implicit. If a folder name is encountered, it is just that: a folder, without its contents.

Since the script logic is complicated, it could be said that the script may generate *any* possible subset of files and directories from the given file tree.

I'd like to be able to convert this "simple" list into an "include list file" suitable for 7-Zip command line.

(If I'm not mistaken, this was possible with pkzip25 command line).

Thanks,
Shmuel

Why do you need folder item without subitems?

There could be various reasons to want to preserve such items in the archive, the least important of them being it would require additional work from my script to track if the item had subitems.

As an example, if such items aren't preserved, one wouldn't be able to say if they at all existed in the source tree, or if they were renamed, deleted, etc.

More importantly, however, would be to have this ability (via some switch maybe?) and let the user decide whether it is suited for the task at hand.

Thanks,
Shmuel

There is no such switch now.
That is why I'm asking about your task.
So can you tell me why do you want to store folder item without subitems?
Don't tell me about your script. I need information about the task on more high level.

Well, you've answered my initial question: this isn't possible to do with 7-Zip at the moment.

With regards to my script: it was mentioned only after you asked "Show some example of your task". Otherwise, I've zero interest in advertising my scripts. :)

With regards to justifying of this feature: I wouldn't be calling it feature, but rather "most basic functionality". The directories (empty or not), along with their metadata, are part of file tree information, and it is the user who decides what part of it is needed and what isn't.

One could also ask: "Why do you need to put empty (zero-sized) files into the archive?"

Don't take the above as criticism: you have created and are maintaining a great product, and I'm grateful for it, irrespectively of whether you implement some feature I need now.

Thanks,
Shmuel

- One could also ask: "Why do you need to put empty (zero-sized) files into the
archive?"

One could also ask: "Why do you need to put nonempty (nonzero-sized) file into the archive as empty (zero-sized) file?"

>> One could also ask: "Why do you need to put nonempty (nonzero-sized) file into the archive as empty (zero-sized) file?"

Igor, I'd like to assure you I've a good answer to this question. But this discussion is obviously leading to nowhere. So, thank you again.

-- Shmuel

Still the question remains: why to have recurse switch which never works?
If I want to compress all files in the current folder (which has subfolders) all of these commands produce the same result (which includes subfolders):
7z a archive
7z a -r- archive
7z a -r0 archive
7z a -r archive
What is the difference between several -r switches then?

-r affects only searching,
-r *.cpp
searches *.cpp in all subdirectories.

I don't know why, but if you really want to compress files in a folders without any subfolders, you can use a such command:

7z a myarch.7z FolderToPack\*.?*

This command assumes, that most files have and extension, and most folders have not

7z a myarch.7z FolderToPack\*.?*
Yes, I know about this workaround (and I use it) but it's still a workaround. And it does not work in all possible cases.
As for 'why' - I think it's quite a common task to compress all files in a folder without its subfolders and why to restrict users - this is the question. :)

> I think it's quite a common task to compress all files in a folder without its subfolders...

May be you are right, but I have never used this in real life. Personally, I think that one, who really need this should review a hierarсhy of files he/she store on filesystem. When it's needed to save files in some folder, most likely it's needed to save any depended data that should be stored in subfolders. If not, it means data saved selectively, no matter: some files in target folder, all files in target folder without subfolders, all files in target folder and files of 1-st level subfolders, all files with 'read only' attribute, etc. That all are not 'common cases'.

Strategically, general purpose utility have to concentrate to work best with real common cases. For no evident cases it's enough to have a workaround. The reason is that the developer(s) have limited time resources.

If you want to convince the developer of your case is common, you should at least describe associated real situations.

All the above is my personal opinion, may be I don't know a task that really needs disabled recursion. And sorry for my English. Have a good day!

> how one can specify an *arbitrary* set of files and folders (both empty and non-empty ones)
> to be included into the archive (via a list file)

An example of using file lists:

# FullBackup.cmd:
"C:\Program Files\7-Zip\7z.exe" a C:\Projects\7-Zip\FullBackup_%DATE%.7z -ir@C:\Projects\7-Zip\DirList.txt -xr@C:\Projects\7-Zip\ExcludeList.txt -mx7 > Backup.log

# DiffBackup.cmd:
"C:\Program Files\7-Zip\7z.exe" u C:\Projects\7-Zip\FullBackup_%DATE%.7z -u- -up0q0r2x0y2z0w2!C:\Projects\7-Zip\DiffBackup_%DATE%.7z -ir@C:\Projects\7-Zip\DirList.txt -xr@C:\Projects\7-Zip\ExcludeList.txt -mx7 > Backup.log

# DirList.txt:
C:\Projects\7-Zip\TestRoot\TestDir1
C:\Projects\7-Zip\TestRoot\TestDir2

# ExcludeList.txt:
*.tmp
*.bak

You may wish to instruct your script to put all the directories you want in DirList.txt, and to put all the subdirectories you don't want - in ExcludeList.txt.

Hope this helps

Ok, "real example":
By default Visual Studio keeps all source codes files in a project folder and creates object and exe files in subfolders Release and Debug.
If to create a project for Windows Mobile 5.0 application in Visuat Studio 2005/2008 the subfolder will be named as "Windows Mobile 5.0 Pocket PC SDK (ARMV4I)" (which includes dot)
Now if I want to backup all source files I don't need Release or Debug folders at all - they will increase the size of the archive and actually are useless for backup purposes. Of course there are several workarounds for this:
1. 7z a source_backup *.* - won't include subfolders Release and Debug because they don't have extension but it will include "Windows Mobile 5.0 Pocket PC SDK (ARMV4I)"
2. 7z a source_backup *.cpp *.h *.rc *.ico .. - this way I need to include all possible source files - easy to miss some important file
3. 7z a source_backup -x!Release\* -x!Debug\* .. - in this case I need to include all subfolders I don't need into the command line which makes the command line longer or more complex.
4. Reorganize source folder so Release, Debug etc won't be subfolders of the folder with source files.
But all I need is an easy and simple command to backup source files!

What about *.ncb and *.suo files?
Do you need to backup them?

1) The dot in "Windows Mobile 5.0 Pocket PC SDK (ARMV4I)" has no matter in this case. Is there a dot symbol in any 1st level subdirectory names? If not, the workaround is OK.

2) As for me, the variant 2 is bad of course. But variant 3 is quite OK. The long command line no matters. You may wish to place the command in cmd-file and call it from Windows scheduler. And move the result on another computer in network via FTP. This free your memory for more creative tasks, and let your computer do uninteresting work for you.

Well, suo files are not so big so I can live with them.
yes, ncb files can be quite big and not needed in the backup so better exclude them.

Anyway, is this still not a good example of a folder where subfolders are not needed?
Most of other compression utilities (except TAR, maybe) have such an option.
And speaking of "missing" options: the command 'move' - do you think it's not needed either?

1) no, it's not. The command 7z a Folder\*.* will still compress subfolders with dot in their name
2) long command matters if I have to type it manually. As for cmd-file - if a new subfolder is added a the later stage (say, I added new platform "Window Mobile 2003") I will need not to forget to add this folder to the cmd-file.

I'm still thinking about best way to implement some additional file search modes.
"Move" command - maybe later.

1) I think I was misunderstood. If folder "Windows Mobile 5.0 Pocket PC SDK (ARMV4I)" contains no subfolders with dot in their names, the workaround will work:
7z a "Windows Mobile 5.0 Pocket PC SDK (ARMV4I)\*.?*"

2) I mean to have a cmd-file in each project's directory. Yes, you have to copy and correct a new cmd-file for every new project. But with it, you will backup your data much faster, as double-click on cmd-file is much faster than opening console and entering a command. Even if you use a file manager.