rename cmd (c++) behavior on ESS

[shibboleth]

on an ESS, rename will occasionally report successful status, but this is misleading as one particular symptom seems to suggest: in my application, the next action after a rename is to get a file handle, and rarely this will result in "file not found". the same application is run on a single filesystem & this never happens.

is this due to what i perceive to be that rename merely makes a new link (or shadow), and then forks the actual move, which is rarely incompleted before parent process attempts to define a file handle for the new location?

this scenario is extremely difficult to faithfully reproduce

 

[Nothinman]

You should probably tell us what an ESS is before we can make any educated guesses. But AFAIK a rename should be a single syscall and thus atomic within the app calling rename(2). Even if the rename operation created a hard link with the new name and then removes the old name in two operations the file will just be available under both names for a small amount of time, there is no data moved during a rename unless you're moving across filesystems and then it's equivalent to a copy and delete.

 

[shibboleth]

right, sorry. ESS: IBM's implementation of a very large enterprise storage "array".

i agree rename should be a vanilla syscall, but i think it's forking. my recent experience w/ similar coding in java has indicated you can choose whether or not to block at this call. because this is a c++ thing, all documentation suggests (but does not explicitly say) this blocks until ERRNO is assigned a value, and thusly this called is blocked. but as indicated, i can (rarely) reproduce a symptom to suggest this is a forked call - and now i'm deeply in the realm of eSpeculating - the return code is from a successful call to fork. and again, yes, i agree that across file systems it's equivalent to cp & then rm.

IBM advertises their ESS is transparent, and all applications implementing what are in effect OS built-ins should not have unexpected/unanticipated behavior [citation desperately lacking]

 

[Nothinman]

Can you run the app through strace, that should tell you whether it's forking or not. If you're just doing 'mv' on the cli then it's definitely not forking.

 

[shibboleth]

ah yes. using truss, it seems to be the case it's a direct kernel/system call, and not a forked-to-unix-mv call.

mystery remains as to why immediately following a reported failure to rename a subsequent rename always succeeds. sadly, the design must stand; so off i kluge.

thanks for responding.