search

pombreda / theunarchiver-migrated

Mac, Linux and Windows universal unarchiver. CLI everywhere and MAC Gui. Objective-C, GPL-licensed. Originally from code.google.com/p/theunarchiver
Other
1 stars 0 forks source link

Smarter destination folder naming for duplicates #184

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I expanded a file named auctex-11.85.tar.gz twice. The first time it was 
expanded into a folder 
named auctex-11.85. The second time the destination folder name used was 
auctex-11-1.85. 
Maybe it should be auctex-11.85-1?

Original issue reported on code.google.com by rocionav...@gmail.com on 18 Aug 2009 at 2:51

GoogleCodeExporter commented 9 years ago 
This is hard to get right. If it was named something.app, then the correct name 
is something-1.app, not 
something.app-1. Same for any other kind of bundle. I don't know if there's a 
good way to handle this.

I'll leave the issue here for now in case anyone can come up with a good 
solution for how to generate names.

Original comment by paracel...@gmail.com on 20 Aug 2009 at 1:21

GoogleCodeExporter commented 9 years ago 
Could you not check to see whether the string after the last dot in a filename 
about
to be written to the filesystem is an extension belonging to a registered 
filetype?
Then, if it is not, append the incremented string to the end of the filename.
Otherwise, append it to the end of the sting preceding the last dot.

This would not fix the problem in cases where you are extracting a file for 
which an
appropriate handler is not installed, but I imagine it would be a little more 
elegant
than the current situation.

Amazing that nobody has proposed some kind of universally acceptable way to 
handle
this situation, as it's not unique to this software or even this platform, and 
the
challenges and considerations appear to be more-or-less the same. At least, I am
unaware of such a solution.

Original comment by mokojum...@gmail.com on 20 Aug 2009 at 3:13

GoogleCodeExporter commented 9 years ago 
Since LaunchServices is such a mess, it's probably hard to actually check just 
an extension.

But [NSFileManager isFilePackageAtPath:] might be able to do it, so that's one 
idea. Either way, it'll have to wait 
until after 2.0. But that probably has its own problems, like what happens if 
somebody makes a regular file with 
the same name as a bundle being unpacked...

Original comment by paracel...@gmail.com on 20 Aug 2009 at 4:33

GoogleCodeExporter commented 9 years ago 
Maybe it's a stupid idea... if you put the number before the file name?
The example above should results like this:
auctex-11.85.tar.gz >>>
    auctex-11.85
    1-auctex-11.85
    2-auctex-11.85
    and so on...

Original comment by mac.marc...@gmail.com on 13 Apr 2010 at 5:48