The selected file could not be copied, because no file by that name exists

I do not know why it would fail.

Could you share one of the failing images so I could test with my version?

Did that start happening after you upgraded or is 1.4 the first version you used?

Thank you.
Alexis Wilke

It's simple: don't use capital letters in filename. All you have to do is rename your images.

Megs

Ah! I see it... I don't think we need that line of code here?!

gallerix_process_file($source, $destination, $delete = FALSE) {
  $source = drupal_strtolower($source);

The attached patch should fix the problem.

Thank you.
Alexis

Okay, I see that there are several problems actually. There are two other places where the extension is being checked and uses a substr(..., -4) which is incorrect since the extension can be 3 or 4 letters (.jpg or .jpeg). We need to fix all those little problems!

More soon.
Alexis

Yes, it would be nice to know whether #4 helps you already, but that would need to be applied against the -dev version. There are some other problems in regard to upper/lower case, but what you described should be fixed with that patch.

Thank you.
Alexis

I've now applied many of the changes to the Zip Archive support...

The 1.x-dev should work a lot better in that regard.

Were you using a zip file? Or always images one by one?

The development version also includes the fix I mentioned earlier removing improper "lowercasing" the file name.

Thank you.
Alexis Wilke

mrwhizkid,

Note: it takes about 12h for the 1.x-dev to refresh... Drupal does that so you have time to upload many changes before a new version is generated.

I guess I have to test a single file too... 8-) The files are expected to go in a sub-folder and it could be that it is saved in the table without that path when it should be there. For the zip files, the path inside the zip file was added to the filename and that would not work at all.

Thank you.
Alexis

The same to me.

The new 6.x-1.x-dev fix the views problem but doesn't allow to upload via repository and/or single images.

Error uploading file (sites/default/files/gallerix/repository/BF_Kristina_006.jpg)
Error uploading file (sites/default/files/gallerix/repository/BF_Kristina_021.jpg)
Error uploading file (sites/default/files/gallerix/repository/BF_Kristina_019.jpg)
Error uploading file (sites/default/files/gallerix/repository/BF_Kristina_001.jpg)
Error uploading file (sites/default/files/gallerix/repository/BF_Kristina_038.jpg)
Error uploading file (sites/default/files/gallerix/repository/BF_Kristina_044.jpg)
Error uploading file (sites/default/files/gallerix/repository/BF_Kristina_008.jpg)
Error uploading file (sites/default/files/gallerix/repository/BF_Kristina_011.jpg)

Okay, I checked in another fix. One variable was wrong in the upload code.

Let me know if that fixes this problem.

Thank you.
Alexis

Okay, so... Are you saying that we should not allow users to edit a Name once it was saved? I think that your previous code was such that it would disable all names, not just the system names. Is that correct? It probably makes sense because users will lose access to all the files with the previous name, but I'm not too sure we want to totally prevent the editing because the users may want to think about it for a couple days... and change the name then.

And indeed the #disabled prevents the #default_value from working... So I switch to #value if disabled. Bad Core!

Do you still have upload problems otherwise?

Thank you.
Alexis

P.S. I did an update... there will be yet another -dev version.

Okay, i've tried the new dev-version from today.

After uploading images i get a new message:

Access denied
You are not authorized to access this page.

I'm logged in as Admin.

When i call the album i could see the gallery description but no images and i get the message: This album is currently empty.

Ciao, Megs

Are you using Private Upload features? Or is your files folder under sites/default/files?

Are you using the secure upload feature?

I tested with the current version and it seems to work just fine, but I don't use private files or the secure feature of gallerix.

http://gallery.m2osw.com/node/5

Thank you.
Alexis

FYI, I've applied another fix, not too sure why it would generate an access denied but there was a problem with the View.

I'm using public download method and no secure mode.

Maybe i will install a fresh, clean drupal, with only the core modules, views and gallerix, and test it again.

Ciao, Megs

I have installed a 'fresh' and clean drupal. Only gallerix, views and core modules, no private download, no security mode.
The Problem is still the same: Access denied
You are not authorized to access this page.

P.S. Without views module the problem is the same

Okay, I found the reason for the access denied page, but I still don't know why the image isn't saved correctly...

  case 'manage':
    // We can only manage if there's at least one picture in the album. By checking the default,
    // we know there must be at least one picture present.
    $access = !empty($node->gallerix['default']);
    break;

As you can see, if there isn't an image, then you're denied access. I guess that's a problem when the image fails loading... but since the image should load just fine!

More soon.
Alexis

Okay! Got it...

The INSERT SQL statement would not include the sort which had a default of 0. 0 is not considered a correct sort order.

So I fixed the INSERT and the .install file with a better default (although I don't use the default since each picture should have a different sort.)

This time, it will work! Thank you for your patience...
Alexis

Cool 8-)

I'm marking this as fixed then.

Alexis

I also can confirm: the issue is fixed.
Thank you, good work

Ciao, Megs