Copy link to clipboard
Copied
We upgraded from CF10 to CF12 and some drive configurations and now CFZIP code no longers works.
The files we are trying to zip are now on a virtual drive, which I have setup on the IIS webserver, where as the old location
was a drive attached to the webserver and assigned a local drive letter.
Do the old location was like e:\logs\filename.ext
the new location is something like http:\\webserver\logs1\filename.ext ( where logs1 is the virtual drive )
No matter what I am getting a basically file not found error when trying to access the virtual drive.
Any help would be greatly appreciated, Note, I am not the expert coldfusion programmer...
Regards
Copy link to clipboard
Copied
First: ColdFusion, like every other program in Windows, runs with the user rights of a specific user. When you log on and run a program yourself, that program runs with your user rights. Since ColdFusion runs as a service, it runs with the user rights of some service-specific user account or security context. By default, that is "Local System", which has very extensive local permissions, but doesn't have any network permissions. That security context can't log into remote filesystems. You can resolve this by creating a new user account that does have access to these filesystems, then configuring ColdFusion to run using that account. That account will need a minimal set of permissions to allow CF itself to run, and this is documented pretty well in the various ColdFusion security/hardening guides on the Adobe site.
Second: I'm not sure exactly what you mean when you say the new location is accessed via HTTP. That will let you read files via an HTTP client, but will not let you access files as if they were on a local or remote filesystem. HTTP is not a filesystem. For CF to access them, once you resolve the permissions issue mentioned above, they'd have to be on a remote filesystem that you could access via "net use".
Dave Watts, Fig Leaf Software
Copy link to clipboard
Copied
This works:
<cfzip file="c:\perflogs\test.zip" source="c:\perflogs\#ccounty#\#cfilename#" >
so if I have a virtual directory on the webserver setup as logs1 lets say, and assuming the cf user account has access
and rights to that location, I should be able to access and zip the files from that source?
something like
<cfzip file="c:\perflogs\test.zip" source="http:\\webserver\logs1\#ccounty#\#cfilename#" >
Thank you
R
Copy link to clipboard
Copied
No, I don't think that CFZIP has HTTP client functionality built into it. It's looking for a filesystem location as a source. HTTP is not a filesystem location. Creating virtual directories in IIS does not create filesystem locations, it just lets HTTP clients reference files that happen to be somewhere else than on your physical IIS web root.
Dave Watts, Fig Leaf Software
Copy link to clipboard
Copied
Thats my issue how do I access the virtual drive with the cfzip.
This works fine with other cf tags
<cfcontent type="image/tif" deleteFile = "no" file = "http://webserver/logs1/#county#/#A#" >
it will serve up the image all day long, but it will NOT work with the CFZIP tag.
R
Copy link to clipboard
Copied
You keep talking about a virtual drive. A HTTP URL is not a virtual drive. It might point to a file within a virtual drive, but it itself is not a virtual drive. You need something that you could get to from a command prompt, basically.
Some CF tags will let you use HTTP URLs for some things, other CF tags will not.
Dave Watts, Fig Leaf Software
Copy link to clipboard
Copied
Ok. so in the above, this works:
<cfcontent type="image/tif" deleteFile = "no" file = "http://webserver/logs1/#county#/#A#" >
it will serve the image file(s) from that location.
Now, I know how I can allow a user to select multiple files, but what I cant get to work is how to take those selections and zip them up and return them to the website user. The images are now at a different drive location that is NOT a local drive letter on the webserver, so I setup the virtual directory if you will of the logs1.
From what I understand or what I have found so far, it appears that CFZIP will not allow me access to that location. I know the user that CF is using has access to them because that is evident in the above line where it will serve the image the user clicks on and downloads it to them just fine.
Sorry I guess in my mind I am being clear, CFZIP will not read the source files from the virtual directory Logs1, on the webserver, but other CF tags do and I was wanting to know if I am just being stupid ( which is not hard for me... ) or if indeed that is the case.
Copy link to clipboard
Copied
Some CF tags will work with HTTP URLs. Others will not. CFCONTENT appears to do this. CFZIP appears not to. A tag that lets you read one file is more likely to work with an HTTP URL than a tag that lets you read multiple files, or write to a file. CFZIP lets you read multiple files, and to do that it needs access to a filesystem. An HTTP URL is not a filesystem, it's a pointer to one and exactly one thing - no more and no less.
You will need access to a filesystem instead of one or more HTTP URLs to use CFZIP. And, once you're accessing that filesystem, CF permissions will once again come into play, because accessing filesystems is not the same as accessing HTTP URLs. Basically, if the filesystem is remote, you will need create a new user account for CF, configure that account to have the local permissions it needs, be able to log into your computer as the CF user, and see if you can access the remote filesystem with that account.
You keep talking about a virtual directory. That is something that only makes sense in the context of a web server. To use CFZIP and many other CF tags (but not all CF tags), you need to be able to access the files through a file server. This isn't a matter of being stupid, or a limitation in how CF works, it's just the way things are. Some things can be done via HTTP, but other things can't.
Dave Watts, Fig Leaf Software
Copy link to clipboard
Copied
You _can_ use CFHTTP to get/put files, then use CFZIP once the file is local.
HTH,
^ _ ^
Copy link to clipboard
Copied
Right, but you don't have a way to know what files there are to get unless you can make an HTTP request to get a list of them, then make another HTTP request for each individual file. You can't simply traverse it like you would a filesystem.
Dave Watts, Fig Leaf Software
Copy link to clipboard
Copied
True, but extrapolating from OPs reply (post #2), the files are programmatically being zipped, anyway, so the first CFHTTP would get the file name(s), then iterate over the results to get then zip the files, and if needed a third CFHTTP to place the zip file on the server.
Just a thot.
V/r,
^ _ ^
Copy link to clipboard
Copied
No, it's not a bad thought at all! I was mostly replying for the benefit of the OP, who would have to understand the required mechanism.
Dave Watts, Fig Leaf Software
Copy link to clipboard
Copied
Apologies. I misunderstood the context.
@robertm1034314, the method Dave and I were discussing is probably the optimal methodology for what you are trying to accomplish.
HTH,
^ _ ^
UPDATE: Sorry.. I meant CFFTP to read the remote directory, get/put files, etc.
Copy link to clipboard
Copied
Thanks Mr. Watts and Wolfshade.
I will play with that and see what happens, my concern is some of these files can be rather large, so 1st glance it would seem troublesome to go get the files and move them to a local drive, write them, then zip them, then server them out to the requestor, then
delete the files, I think I would have to put some sort of limiter on the number of files they could select at 1 time.
Interesting situation...
R
Copy link to clipboard
Copied
You wouldn't necessarily have to place the zip file on the server for the user to download. Once the zip file is created, you don't have to save it to disk, you can keep it in memory and offer it to the user for download. This saves disk space, and you don't have to delete the zip after the user downloads it. (Theoretically)
My theory is incorrect. Apparently, with CFFTP you _have_ to save to disk. There is no keeping it in memory like I did with the upload form. But you don't have to put it back on the server via CFFTP, you can save it locally and offer it to the user for download, then erase it.
^ _ ^