Main Area and Open Discussion > General Software Discussion

Recreate files but without content to target drive

<< < (2/11) > >>

Steven Avery:
Hi Folks,

Good question.  A while back I was also thinking about this with an email program like Eudora when you want to "start fresh" with new data. You might need all the .mbx files (or whatever extension) and optionally the index or table of contents files (those would build themselves) but you want them empty to start, like they are before they receive any mail.  

Then all your mail up to that point could be saved or archived, and you can start receiving mail using the exact same filter structure. (The key point, without the empty files the filters will give errors, they do not build on the fly, although maybe in Bat-land you would have that option.)  In a rudimentary form it would be drive-to-drive (eg. c:/myfiles to d:/myfiles ) .. in a slightly more sophisticated form it would be any point-to-point. (e.g c:/myfiles to c:/newfiles/mail ).

Although it is a far less sophisticated need than the one you are mentioning, a tool would be nice, even a two step tool (tree-copy followed by "copy file to empty").

Shalom,
Steven Avery

skwire:
Is there a way to recreate file/folder structure from source to target but without any content?
better yet, is it possible to zip it up?-vixay (June 09, 2009, 07:14 AM)
--- End quote ---

I have this mostly done but have some questions.

1) Do you have need of the recreated zero-byte structure?  Or, do you just care about the resulting zip file?  The reason I ask is that if you don't, I'll just build the new structure in the user's temp folder and delete it when I'm done.  Make sense?

2) I currently have the zip being generated with relative paths set.  What this means is that you can unzip the resulting zip file to any folder and the structure will be built there.  Is that okay?

skwire:
Download Zero Zipper and see if this is what you had in mind.



Download: http://skwire.dcmembers.com/apps/zero_zipper/ZeroZipper.zip

vixay:
SkWire that's perfect!  :up: :up: And exactly what i had in mind! Pure genius! I tried it out and works. And you guys did this in less than 24 hours! Sending some credits your way.

And you are right, I needed the 0 byte files not just the folders.

Some further thoughts. The test zip file i created has 18,375 files and weighs in at 3.27 MB. That must mean that the filenames storage takes up that much space. And that zips don't optimize that part? or something else?

Scanning for files was slower than everything/locate, i don't know how they do it, but they can scan filenames super fast. just a thought, to see if it could be sped up. Since you don't actually need to touch the file, and just need the information from the MFT.

The date/time is not preserved for filenames. This was not an original requirement but when i think about it, it's better to have that information preserved  (not required though). If it will make the program slower then it should not be there (or maybe as an optional thing).

Can you share your ideas on how you did it? You used IZarc to compress, did you just use flags for the command line , or dump the filename list and then create the zip?

Fabulous work!

f0dder:
Some further thoughts. The test zip file i created has 18,375 files and weighs in at 3.27 MB. That must mean that the filenames storage takes up that much space. And that zips don't optimize that part? or something else?-vixay (June 10, 2009, 07:10 AM)
--- End quote ---
Indeed they don't - it would make reading the zip folder structure much slower, and to achieve any kind of reasonable compression you'd need to compress just the filenames... which would mean quite a restructure of the file format, and require either unpacking all the filename information at once, or some "somewhat interesting" code.

Scanning for files was slower than everything/locate, i don't know how they do it, but they can scan filenames super fast. just a thought, to see if it could be sped up. Since you don't actually need to touch the file, and just need the information from the MFT.-vixay (June 10, 2009, 07:10 AM)
--- End quote ---
Locate builds an efficient index file, which can be read faster than the MFT (and doesn't have security-check overhead either). Everything, as far as I can tell, scans the MFT directly (which is why it requires administrator privileges).

The date/time is not preserved for filenames. This was not an original requirement but when i think about it, it's better to have that information preserved  (not required though). If it will make the program slower then it should not be there (or maybe as an optional thing).-vixay (June 10, 2009, 07:10 AM)
--- End quote ---
It shouldn't make the zip-creation slower, since you also get file dates when scanning for files.

PS: you could try zipping the generated zipfile, might be able to shave off a little of the filenames.

Navigation

[0] Message Index

[#] Next page

[*] Previous page