Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I archive directory ending with dots. When unarchive I get the directory without dots at the end.
Moreover, suppose I archive several directories with the same name but with different number of dots at the end of each directory (e.g. "d." "d.." "d…"), each directory contains file with the same name but with different contents.
When I enter in FAR all is OK. Three directories with three files are there.
But when unarchiving I get one directory with one (naturally) file, two other files are lost without any message.
7-Zip happily outputs that "Everything is Ok" and that three directories and three files are successfully extracted.
I meant: When I enter archive in FAR all is OK.
That case is not simple.
Most windows program can't work with such folders.
Try for example to open that folder with Windows Explorer.
Let's suppose that some user will extract such archive with "dir." to some folder.
But then that user will try to open that folder in Explorer - fail.
Then the user will try to delete that folder in Explorer - fail.
I suppose it's not good that FAR creates such folder in default mode.
You can say that there is similar situation with long path (longer than 255 characters). But there is difference. Windows API doesn't work (without UNC path) with long path. But Windows API works with "name." filenames. It just removes dots from the end.
7-Zip works so: if there is error, it tries to use UNC. But there is no error in case of create "dir." folder command.
FAR works another way.
Windows Explorer does not enter "d." folder but enters "d.." and "d…" folders (though not opening containing files).
Yes, I know that MSDN recommends to NOT end directory (and file) name with dot.
But bad thing is that 7-Zip says "Everything is Ok" and that all folders and files are successfully extracted.
(RAR at least ouputs error messges that "The system cannot find the path specified.")
Now I see some additional problems with such names.
How did you create that acrhive?
I suppose you must have wrong files even in archive, if you archive such folders.
I've created such folders and files by FAR.
I can send you the archive.
Interestingly, when I look into the archive by FAR then both in "d" and "d." folders I see file from "d" folder, with "d.." and "d…" folders all is OK.
I suppose I can make some changes in 7-Zip.
It will replace dots and spaces at the end of name to '_' (underscore) characters when you extact archive.
I suppose it can solve some problems.
The case when you create such archive is more complex.
It requires more changes in source code for support. I'll think it more.
If you replace dots with underscore, paths after archive extracting will not correspond to the initial ones.
I doubt it is correct.
May be you need to use "\\?\" prefix at the beginning of the directory name (MSDN: Naming Files, Paths, and Namespaces) when creating directories during extracting.
From command prompt "md S:\s…" creates directory without dots.
But "md \\?\S:\s…" creates directory with dots.
I know that I create such directory / files.
BUT I think IT'S BAD IDEA to create such files and directories.
User will not be able to open such files.
There is no programs in Windows that support them.
Only FAR can copy/rename/delete them.
So I suppose the best solution for 7-Zip:
- It doesn't create "bad" files / directories.
- it replaces "bad" characters to '_'. So when you extract such archive, you will have different directories in case of d. d.. d…
So in any case the user will have "good" file names and directories.
- "If you replace dots with underscore, paths after archive extracting will not correspond to the initial ones."
It's small disadvantage in comparison with with "bad name" problems in Windows.
Do you have any real case when you use "bad name" directory in real system for some purposes?
Correction: I know that I CAN create such directory / files with Windows API.
May be we\\\\\\\'ll contunue our conversation by email in russian ?
Or you prefer to continue it here ?
That topic is important for other users too.
So we must continue at this forum thread.
I'm absolutely sure that spaces at the end of folder/file name is evil,
but also I believe that if (for any reason) user already has such folder/file then such existing filesystem MUST be preserved during archiving/unarchiving process.
If user has such folder/file, then (s)he knows how to treat it.
My "real case" is following:
I've encountered the problem when archived my music archive. Folder names in the archive correspond to the names of music albums. One of Deep Purple's albums (The Battle Rages On…) has ellipsis at the end. I know that I can use ellipsis symbol, but I used three dots.
My solution after fixing :
1) 7-Zip will work with existing "bad names" (even store them to archive).
2) 7-Zip will not create new "bad" names by default. Instead it will replace "bad" names to "good" names. Maybe it will create original names with some switch (like -spf switch).
- If you have music files in folder "name…", probably there is any music player in Windows that can open such files. It senseless.
2) 7-Zip will not create new "bad" names in filesystem.
1) 7-Zip has already stored existing "bad names" to archive.
2) What do you mean "create new "bad" names in filesystem" ?
If "bad" names are already in filesystem (before archiving), then such "bad" names are not NEW.
7-Zip of course must not invent any NEW folder/file names.
It merely has to extract folders/files with names exactly corresponding to the ones in archive.
There is such music player.
Its name is Winamp :-)
1) current version of 7-Zip can store incorrect files In most cases, if there are bad names.
Next version will store correctly.
2) 7-Zip will not call CreateFile(bad name) / CreateFolder (bad name). Instead it will call CreateFolder (good name). So 7-Zip will not create any new files folders with bad names.
3) Users don't need such bad names in their system in 99.9% cases.
For example, the name "dir…" is not bad for linux system (as I suppose).
Some linux user compresses such folder and sends archive to another user with Windows, If the user in Windows extracts that archive, and if it will create bad name, the user will try to open files in bad folder - fail. Then the user will try to delete hat folder in explorer - fail. The user will think that something is crashed in system. We don't need it.
If it will extract to "dir___", the user will have no any troubles.
4) What version of WinAmp / what version of Windows?
Does it support any "bad" names?
1) current version of 7-Zip can store incorrect files In some cases, when there are similar bad names (like dir.\1.txt and dir..\1.txt) .
Next version will store correctly in all cases as I suppose.
FWIW, I must say it doesn't sound a good idea to start changing directory or file names from what was used originally when the archive was created. It shouldn't be up to 7-zip to "decide" what to do. If a file or directory name was created from a valid directory structure, 7-zip should try its best to respect the original.
IMHO, it is not up to 7-zip to make guesses about which fs is going to be the destiny of the expanded archive. Either the character is supported or not; but automatically changing it? In such case, shouldn't the user be asked what he wants to do, or at least be warned, instead of making automatic decisions? The problem may reside in the original file manager (FAR or whichever) or elsewhere (it doesn't really matters); if Windows accepted a file or directory name at first (before generating the archive), then 7-zip should try to respect it. Purposely and automatically changing characters sounds, at first glance, an open door for other potential unintentional consequences.
I use Win7 64 bit.
1) My existing command line 7-Zip 9.20 32b correctly (as I see it through FAR plugin) stores the following: "d\s.txt", "d.\s.txt", "d..\s.txt", "d…\s.txt".
4) Winamp 5.6 successfully adds beforementioned "The Battle Rages On…" folder with corresponding .mp3 songs.
Also Winamp 5.6 happily plays these .mp3 when I press Enter on them either in Windows Explorer or in FAR.
I absolutely agree with Ady.
He has exactly expressed my opinion using so many english words :-)
- Windows Explorer does not enter "d." folder but enters "d.." and "d…" folders (though not opening containing files).
- Also Winamp 5.6 happily plays these .mp3 when I press Enter on them either in Windows Explorer or in FAR.
So what cases you can enter bad folders and open files from them?
Probably different versions of Windows has different problems with such "dots" cases. I can't open "dir…" in Explorer in 64-bit Windows XP.
- NTFS supports it.
- Basic Win API doesn't support it (or supports partially in some case in some versions of Windows)
- Only Win API with special smart technics supports it.
More than 99% of programs use basic Win API, so they have problems with such names.
- If a file or directory name was created from a valid directory structure, 7-zip should try its best to respect the original.
You think about it in such scheme: I created archive and I extract archive. I had the problem in past and I will have same problem in future.
But users extract archives created by another users. So we have another situation, where the user can get the problem from external source. Moreover most of users don't understand that problem. And that problem can be too complicated for them to fix it. I'm sure that 99% of users don't need that problem with names.
I have the following test directory structure:
All s.txt files have different contents. There is only one problem in Windows Explorer: when I enter "d." folder I see s.txt from "d" folder. All other folders/files are correctly accessible form Windows Explorer.
So .mp3 files from folder with three dots at the end are "launched" in Winamp normally.
>If a file or directory name was created from a valid directory structure, 7-zip should try its best to respect the original.
Dots at the end of folders'/files' names is a valid directory structure, but 7-Zip does not and (as I see) is not going to respect the original directory structure.
>I created archive and I extract archive. I had the problem in past and I will have same problem in future.
You are absolutely wrong.
I had no problems (with folder ended with three dots), so I do not want to have problems created by 7-Zip during archiving/unarchiving process.
Try also another systems, like Windows XP.
And try also "spaces" instead of "dots".
-Dots at the end of folders'/files' names is a valid directory structure.
Dots at the end is undesirable thing in Windows. Previous versions of Windows had big problems with them. Maybe Windows 7 works better with dots. But it's still undesirable as I suppose.
If someone can create the table of all dots/space problems for each version of Windows, maybe it will be possible to dispatch the code for different of Windows. But now it's simpler to use "_" to avoid problems for most users.
It\'s not just different versions of Windows, it\'s \'volumes\' (disks) containing different file systems, such as Fat16, Fat32, NTFS, and others, any of which can be mounted by any version of Windows (with obvious restrictions… for example, Fat32 was only available in Windows 95 after OSR2, and NTFS in more recent versions of (desktop) Windows only.)
Also, other operating systems and apps that have .7z compatibility can have entirely different file structures with different reserved variables and characters.
Most flash/thumb drives are formatted by default with Fat32, I\'ve noticed…
Sometime recently, I checked to see if I could find a page showing the problems for each version of Windows as Igor requested. I found a page on msdn_microsoft_com which was updated in 10/2012. It discusses the differences between each of the file systems used by Windows and the relative benefits and drawbacks, with filenames also discussed, such as why paths and \'long filenames\' (newer than FAT16) are limited to 255 characters, why using the //*/ prefix allows paths up to 32768 characters but with 255-character limits on the names of the directories between the \"/\" marks and some of the var/expansion text capabilities of the \'standard\' long-filename system removed.
Windows 7 probably has problems with dots the same as earlier versions in order to maintain compatibility with DOS file structures (unless you prevent the file system from creating the \"short (8.3) filenames\" as it does by default). At least, NTFS does that by default, according to MS. Does Win7 (or 8?) use NTFS in most cases?
I didn\'t know some of that until I read it recently, and I don\'t have the URL available right now, but from what was said earlier in this thread, you probably already know those things.
I agree with Igor: I think using \"_\" to avoid incompatibilities between file systems is the safest option for now, but that\'s just my opinion.
One last thing I wonder about: Does surrounding the file path with quotation marks, such as \"d..\\s.txt\" and \"d…\\s.txt\" solve the problem?