nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Invisible Mac Files

CalvinFold

We've found MediaBin 4.6.1 to be very Mac-unfriendly. It's detecting all sorts of invisible files, including what I believe to be the Resource Forks, and giving errors.

For example:

--it's erroring an invisible file starting with "._" for every document ingested

--whenever these errors are generated, a spurious "_MACOSX" folder shows-up in the catalog directory structure, and is empty

--it also sees invisible ICON files.

What is strange is all the files it "sees" begin with a period (.) and thus should be ignored, at worst, by Mac and UNIX conventions. They are system-level invisibles that even Mac users can't see unless they are logged in as root.

Is this an install issue, or a bug, or...?

Find more posts tagged with

Comments

lyman

MediaBin is based on the assumption that files can be repurposed. Therefore if the original was called file.bmp and extracted as a jpeg, the resultant file is called file.jpg.

Due to this logic, MediaBin will not accept as a filename something startingor ending with a ".". While I relaize that UNix and Mac OS have no problems with files names this way, Windows is not as tolerant.

Therefore, the error from the server simply states that files cannot begin or end with a ".".

As to the other issues, please be more explicit about what client you are using? Mac Native Client? Web client? Hot folders?

Thanks,

Lyman Hurd

CalvinFold

Well my point is not that Mac and *nix are "tolerant" of files beginning with periods, it is that they are *properly* dealing with them. These are "hidden" files and should be ignored except at the OS level. Which means an asset manager shouldn't error-out, it should simply ignore them (or deal with them as appropropriate as data). But error? That's just dumping the confusion in the user's lap.

(And to your point, Windows itself is horrible about this too...but if MediaBin is to claim it's truly cross-platform, Interwoven needs to deal with the problem even if Microsoft won't.)

We use both Mac and Web Client (from Mac, Firefox specifically), but not Hot Folders, for cataloging. 99% of our assets originate on Macs, are graphics files, and are cataloged from Macs.

lyman

I will try to ad dit to the feature request list. What would be your expectation? The error returned is not "fatal" in the sense that it will seamlessly go on to the next file (depending of course on how a script is written), but there is the possibility of changing the name to something acceptable.

The problem comes when one tries to repurpose the asset. Currently file.jpg retrieved as a bmp would be changed to file.bmp. If the file were originally names simply .jpg you can see that it would present problems.

Cheers,

Lyman Hurd

AtLeast5RowsInSubTable.rptdesign

CalvinFold

I will try to ad dit to the feature request list. What would be your expectation? The error returned is not "fatal" in the sense that it will seamlessly go on to the next file (depending of course on how a script is written), but there is the possibility of changing the name to something acceptable.

The problem comes when one tries to repurpose the asset. Currently file.jpg retrieved as a bmp would be changed to file.bmp. If the file were originally names simply .jpg you can see that it would present problems.

The expectations would be:

--ignore known OS-level files from any platform (ones that do not match asset names being ingested)

--if the invisible is the same name as an asset (but with the added period at the start), manage it per your system needs....ignore it or keep it merged with it's matching asset

In other words, the user should be blissfully oblivious about invisibles just like they are on their desktop, regardless of platform. Additionally:

--Don't create the empty "MACOSX" folder.

You're helping me offline with the Resource Fork issue, which I think is tied to this somehow. Perhaps the "problem" only occurs when Resource Forks get stripped from Mac files from improper setup?

lyman

The empty "MACOSX" folder is some sort of client issue we can try tracking down. There are two issues with the hidden Mac files;

1) The server will reject a file with a beginning or trailing period independent of the existence of a resource fork. This is a check performed on the filename basically to avoid the kinds of ambiguities described earlier.

2) There also appears to be a problem with the resources that I am sure we can pin down.

I am confident that we can reach the goal line. I look forward to hearning more about the specifics.

Cheers,

Lyman Hurd