Library Image Upload Issue

[Robin]

When uploading either a single image or bulk images I get the
following error:

"access denied (java.io.FilePermission D:\home read)" - full trace
below.

I've read through the posts and seen that this has been an issue in
the past, but don't see a solution that applies here - maybe I can't
see the wood for the trees.

My set up is on a shared host. FC5.0.0, CF8, MySQL5, IIS. I have FC
as a standalone configuration. FUs work brilliantly.

Curiously, I can upload a flash file with no issues.

I'm not using CFImage. I tried creating three separate folders under
the image folder for each "SourceImage", etc., but no joy.

My host allows CFDirectory, CFFile, etc and it is turned on.

The host support guys are wondering why FC refers to the full address
- including the "D:\home", which they say FC shouldn't be trying to
access.

Can anybody suggest what the problem and solution might be?

Cheers

Robin

Stack Trace (top few lines):

java.security.AccessControlException: access denied
(java.io.FilePermission D:\home read) at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:
323) at
java.security.AccessController.checkPermission(AccessController.java:
546) at
java.lang.SecurityManager.checkPermission(SecurityManager.java:
532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.isDirectory(File.java:752) at
coldfusion.runtime.CFPage.DirectoryExists(CFPage.java:2816) at
cfimage2ecfc1609137485$funcCREATEFOLDERPATH.runFunction(D:\home
\mandalainternet.com\wwwroot\farcry\core\packages\formtools\image.cfc:
358) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at
coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:
360) at coldfusion.runtime.UDFMethod
$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at
coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:
59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) at
coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:2471) at
cfimage2ecfc1609137485$funcVALIDATE.runFunction(D:\home
\mandalainternet.com\wwwroot\farcry\core\packages\formtools\image.cfc:
233) at . . .

[modius]

On Aug 20, 3:37 am, Robin <lensl...@gmail.com> wrote:
> When uploading either a single image or bulk images I get the
> following error:
>
> "access denied (java.io.FilePermission D:\home read)" - full trace
> below.

Sounds like you have a permission error and CF is not allowed to write
files to the location you are storing images.

> My set up is on a shared host. FC5.0.0, CF8, MySQL5, IIS. I have FC
> as a standalone configuration. FUs work brilliantly.
>
> Curiously, I can upload a flash file with no issues.

It's possible that the directory containing flash has the right
permissions assigned. If the directory that you are uploading to
doesn't exist then FarCry, via CF, will create the directories for
you. This will mean they'll have permissions relevant to the CF
server, and not necessarily appropriate for your application.

> My host allows CFDirectory, CFFile, etc and it is turned on.
>
> The host support guys are wondering why FC refers to the full address
> - including the "D:\home", which they say FC shouldn't be trying to
> access.

What version of FarCry are you using? v4+ stores a relative file
address. And builds an absolute address for CFFILE based on your
project configuration. In any event FC is not accessing anything --
ColdFusion is. FC just provides the location. As far as I'm aware
CFFILE writes require the absolute path on the server.

> Can anybody suggest what the problem and solution might be?

A permissions problem ;) Try changing the file permissions on the
directory structure where you are writing images eg. ./www/images/*

-- geoff
http://www.daemon.com.au/

[Fritz Dimmel]

Hi,

as already mentioned in another thread, one has to create the images/dmImage/Standard|Source|ThumbnailImage directories manually.

(This should be included into the skeleton, btw.)

Formtools image.cfc checks, if these folders exists, if the don't they start at the root level of all websites (in your case d:\home). I've head the same issue several days ago.

If the folders don't exist, it runs the createDirectory (or sth like this) functions recursively. The first iterations does a: <cfif directoryExists("d:\home")> (i wrote the value here).

You shared hosting account does not have READ permissions for this dir. Your account is settled under, e.g. d:\home\yourAccountNumber\ where you have all permission.

As mentioned, the solution is to create these directories manually, the long term solution would be to create these directories during install process.

Bye,

Fritz 

°================================

| Fritz Dimmel 

| Gassnergasse 14

| 2020 Hollabrunn

| -------------------------------

| Porzellangasse 44-46/14

| 1090 Wien

| -------------------------------

| +43-1-3101365

| +43-660-6000069

| fr...@dimmel.at

| www.dimmel.at

| -------------------------------

| Check this out: http://www.nickthal.com 

°================================

[Tomek Kott]

Hi Fritz,

I tried your solution for my site that is also on a shared server. If I understand correctly, I was to create the folders under the project webroot (say it is www, so that I would be going to localhost/www), www/images/dmImage/Standard, www/images/dmImage/Source, www/images/dmImage/ThumbnailImage.

I tried exactly that, double/triple checking that my case is corrrect. However, the error is still thrown: access denied (java.io.FilePermission /afs read) , where /afs happens to be the root directery if you go by the full path name.

Interestingly enough, there is NO such problem when uploading files!!

I.e., I can delete the dmfile folder (from www/files/) and then try to upload a new file. It creates the dmfile with no problem! I checked (as much as I am able to over webdav) the file permissions on the folders, and they are exactly the same. So, perhaps the solution is to use the file cfc type?

I'm probably not getting a fundamental difference between the two, but it seems that what file upload can do, image upload should also be able to do.

Tomek

[Robin]

Tomek,

Well, I can say that this time it actually worked for me. I too had
checked and double checked and had it fail several times. I had to
recreate my local development for another reason, so I started with a
vanilla install for a standalone configuration.

Once my local FarCry install as working I tried to upload images to
the image library (still local) and there were no problems. The
dmImage folder was created under /images and under dmImages the three
subfolders were created successfully too (SourceImage, StandardImage
and ThmbnailImage). I then pushed the dmImage folder to my host site
and it worked. I can now upload images through my host site.

For the life of me, i can't see what I did wrong up to this point.

What confuses me now is why i can upload a flash file and see the
dmFlash folder created under the 'files' fiolder, but it's empty, even
though the Library Manger tells me the file is there (I've refreshed
everything).

Robin

On Aug 21, 1:39 pm, "Tomek Kott" <tkott.s...@gmail.com> wrote:
> Hi Fritz,
>
> I tried your solution for my site that is also on a shared server. If I
> understand correctly, I was to create the folders under the project webroot
> (say it is www, so that I would be going to localhost/www),
> www/images/dmImage/Standard, www/images/dmImage/Source,
> www/images/dmImage/ThumbnailImage.
>
> I tried exactly that, double/triple checking that my case is corrrect.
> However, the error is still thrown: access denied (java.io.FilePermission
> /afs read) , where /afs happens to be the root directery if you go by the
> full path name.
>
> Interestingly enough, there is NO such problem when uploading files!!
>
> I.e., I can delete the dmfile folder (from www/files/) and then try to
> upload a new file. It creates the dmfile with no problem! I checked (as much
> as I am able to over webdav) the file permissions on the folders, and they
> are exactly the same. So, perhaps the solution is to use the file cfc type?
>
> I'm probably not getting a fundamental difference between the two, but it
> seems that what file upload can do, image upload should also be able to do.
>
> Tomek
>

[Tomek Kott]

Robin,

I had misunderstood the folders that needed to be made. I thought it was Source, Standard, and Thumbnail for some reason. Once I added 'Image' to the rest of those, I was able to upload images just fine. Thanks for pointing out those folders, I would've been lost without it!

Tomek

[Robin]

Hey, glad i could finally give something back Tomek. As I find, the
"devil is usually in the detail", and the detail is what is invariably
assumed by those who work on a project for a long time.

Robin

On Aug 25, 6:01 am, "Tomek Kott" <tkott.s...@gmail.com> wrote:
> Robin,
>
> I had misunderstood the folders that needed to be made. I thought it was
> Source, Standard, and Thumbnail for some reason. Once I added 'Image' to the
> rest of those, I was able to upload images just fine. Thanks for pointing
> out those folders, I would've been lost without it!
>
> Tomek
>