Dan,
What I've found out so far:
The command line task to check digital object CSV columns has a
problem with absolute paths regardless of any file permission
problems.
In atom/lib/task/import/csvDigitalObjectPathsCheckTask.class.php, the
getCsvColumnValues() function returns values from the CSV file. If
these values are full path names, though, they won't match the output
of getImageFiles(), which consists of filenames only, not pathnames.
Suggested fix:
In getCsvColumnValues(), replace:
array_push($values, $row[$imageColumnIndex]);
with:
// Remove absolute path leading to image file.
$relativeFilePath = basename($row[$imageColumnIndex]);
array_push($values, $relativeFilePath);
When I created a modified version of
csvDigitalObjectPathsCheckTask.class.php that included this change, I
got expected results.
Next I will go back to investigating the actual CSV import problem.
Now that my input files are readable by anyone (-rw-rw-r--) and in
directories that anyone can access (drwxrwxr-x), would you expect
running as the www-data user to make any difference?
About Vagrant: I tried using that originally, but I could never get
AtoM to store date values, like creation dates of archival
descriptions. No matter what I entered in the form, it was silently
ignored, and AtoM continued to complain that a required value was
missing. So I switched to a desktop version of Ubuntu in VirtualBox,
which did not have that problem.
Maybe someday I could try a different AtoM Vagrant box version. I
will take a look at those links that you provided if I decide to go
down that path again. Thank you.
-Scott
> To view this discussion on the web visit
https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BB3%2BNRNVOpJiyvhcwBhUW8RJB6U_ReWOV4AaX%3DkpZijA%40mail.gmail.com.