ID:264051
 
Code:
mob/verb
create_savefiles()
var/savefile
savefile_1 = new("savefile_1.sav")
savefile_2 = new("savefile_2.sav")
savefile_3 = new("savefile_3.sav")

savefile_1["document"] << "Some text."
savefile_2["document"] << "More text."
savefile_3["document"] << "Much text."

compress_savefiles()

// Create a new zipfile called "savefiles.zip"
var/zipfile/zipfile = new("./savefiles.zip")

// Import all the savefiles that were created in \
create_savefiles() to my new zipfile.

zipfile.Import("savefile_1.sav","savefile1.sav")
zipfile.Import("savefile_2.sav","savefile2.sav")
zipfile.Import("savefile_3.sav","savefile3.sav")

// It's important to note that zipfile.Import() doesn't \
move the file, it copies it. So I delete the savefiles.

fdel("savefile_1.sav")
fdel("savefile_2.sav")
fdel("savefile_3.sav")

// Close the zipfile. This is important!
zipfile.Close()

read_zipfile_contents()
var/zipfile/zipfile = new("./savefiles.zip")

// Read the contents of savefiles.zip and \
display them.

for(var/file in zipfile.Flist())
usr << file

zipfile.Close()

decompress_savefiles()
var/zipfile/zipfile = new("./savefiles.zip")

// Export all the savefiles from savefiles.zip.
for(var/file in zipfile.Flist())
// @Todo: Export file.

zipfile.Close()


Problem description: The problem with this code is that savefiles imported to the zipfile are put in the end of some weird complex of folders which I have no idea on how they could get there. This is the zipfile I get:

savefiles.zip/
Documents and Settings/
Administrator/
Desktop/
Secret experiment 69/ (this is the project's name)
savefile1.sav
savefile2.sav
savefile3.sav

But the expected result is:

savefiles.zip/
savefile1.sav
savefile2.sav
savefile3.sav

Help please!
I've never used the zipfile library, and don't much feel like looking at it or its documentation if I don't have to, but is there a reason for the following?
var/zipfile/zipfile = new("./savefiles.zip")

Instead of this:
var/zipfile/zipfile = new("savefiles.zip")

This is where I would start; I wonder if it changes anything?
In response to Kuraudo S.
Kuraudo S. wrote:
This is where I would start; I wonder if it changes anything?

I can see where he's coming from with that, but it's unneeded since the current directory is used without needing to specify "." anyway. Removing it should be equivalent, and it shouldn't have anything to do with his problem because that line only decides the location of the zip file itself... I'm not sure why he's getting that problem.
In response to Kuraudo S.
Ah, that was actually an attempt to fix the problem. I saw that Xooxer used it when he created a zipfile in Chatter's source code, so I copied him here... but as Kaioken said, I don't think it changes anything.
I can't find Dantom.zipfile, but I have a sneaking suspicion that your problem lies with Flist(). flist() in DM will allow you to root through all folders on that drive. Perhaps you need to send it a path so that it doesn't default to /?
In response to YMIHere
That's good enough to reach the imported files, but my problem lies in how the zipfile is constructed. Instead of simply copying the files into it, it copies the whole path of folders it takes to reach them (starting from My Documents).

Anyway, you can find the library in hub://Dantom.zipfile.
I think your problem lies in this Import() call. The first argument should be the path. You have it set to the filename, though, which might be causing it to use some sort of default path since it can't find the one you specified. Try this:

zipfile.Import("./","savefile1.sav")
In response to YMIHere
That isn't DM's Flist(), though. It's a method of the zipfile datum. I'm pretty sure his problem lies with the Import() call.
In response to DivineO'peanut
You may have to wait for someone like Lummox for this, since there isn't much to go by in the library itself, it's all internal behavior... but if you're saying it works in Chatters , why not check how it does it in the source?
In response to Xooxer
Xooxer wrote:
I think your problem lies in this Import() call. The first argument should be the path.

That would be the path to the filename you want to store. This isn't the problem. From the zipfile library:
Import(path,name_in_zip)

(The 2nd argument is optional, I think)
Your code stores the entire directory in the zip (still under magic subfolders like Peanut's problem).
In response to Kaioken
The problem is that I don't store files in the zip programmatically. I just use it to extract them from an archive I made manually. I have used it like this before, but I've never seen this behavior. Unfortunately, I can't find my old snippet to refer to.
In response to Kaioken
Hrm, yeah. That makes sense. >.> Guess I need moar coffies before I start giving out code help. :P
In response to Xooxer
Hm, I see. So you didn't use the library for zipfile making... wonder if no one has and it's been bugged ever since? =P Or perhaps an update like 4.0 or later broke it.
In response to Kaioken
The zipfile library has always been a bit iffy about storing files, there was even a point where you could only extract using it. I believe the addition of compression was a quick addition and it may not work as expected.
In response to Nadrew
Well, at least you can always use shell() or a DLL file for that part. Maybe you should try it, Peanut.
[link] should hopefully be helpful.
In response to Jon88
Yeah, that works. Thanks.

*mean look at Xooxer* >:o
In response to Jon88
Thank you very much!
In response to Kaioken
You honestly can't expect me to remember every thread I've made in the past 7 years, can you? :P
In response to Xooxer
Only 3 years! hehe.
Page: 1 2