Talk:Make a backup file

Assumes unix

This task assumes unix, for example: "keep in mind symlinks". (So presumably it's legal to use os-specific code that would fail on windows?) --Rdm 19:43, 9 November 2011 (UTC) Then again, it specifies "avoid external commands" so presumably this means that libc should not be used from non-C languages? I'm not sure which requirements take precedence over which other requirements here. --Rdm 19:46, 9 November 2011 (UTC)

It looks like later versions of Windows do have symbolic links, but I never used symbolic links very much on any platform, so I don't know how important the operational differences are. --Mwn3d 19:50, 9 November 2011 (UTC)

Interesting, and they seem to work. And the "It is assumed" part of this task presumably means that if the program needs administrative privileges, it can be assumed to have them (I do not know what privileges are needed by default to rename or delete these links but administrator is needed by default to create them). --21:53, 9 November 2011 (UTC)

yes, i don't want to introduce another set of complications. and i certainly hope that links in windows can be manipulated without admin privileges though. but actually, the link itself does not need to be manipulated, only the target of the link.--eMBee 03:11, 10 November 2011 (UTC)

the task is written towards unix because that's all i know. :-) if you can help make it more generic, then i'd appreciate that. one of the points is to work out quirks when you deal with renaming files that actually point to a different location.

libc may be used if it is linked to your language runtime or into the executable. what should be avoided is things like exec or popen which fork an external command, and even more so try not to use things like system which execute a shell to run the string you pass. the last one might make the task be a mere wrapper around any UNIX Shell entry.

the reason for avoiding exec is that in some environments executing other commands has its own set of problems. path issues, security, or even simply availability, and also portability. (a solution that executes mv is going to be harder to port to windows than one that uses some libc rename function)--eMBee 03:11, 10 November 2011 (UTC)

You did not address dynamic loading at all (dlopen, ...). Also, you did not give enough detail for me to decide what to do about the case where file rename is implemented in utility which comes with the language and which uses mv on unix and MoveFileW from kernel32 on windows. --Rdm 14:31, 10 November 2011 (UTC)

i think dlopen is ok, i am not sure though, one question i am interested in is: can i deploy a program without relying on dependencies that i can not control? what if a user wants to run the program in a chroot or jail environment where mv might be missing. dlopen would be ok here only if the library to be opened somehow comes with the language, like it is a standard dependency of the language (as opposed to a dependency of just this task). this partly answers the case where the language implements rename using mv because in such a case mv would also be a standard dependency of the language. although i still would like to prefer a version that doesn't rely on external tools and processes.

in any case, if you can not avoid running an external process or if you dlopen a 3rd party library then please point this out in the description.--eMBee 17:07, 10 November 2011 (UTC)

Hmm... this warrants some thought: libc is the portable (documented) interface to the unix kernel. It can hypothetically be a static library but that is extremely rare nowadays -- almost everything requires an external libc. That said, there's also the question of "which libc", and the one used at build time is probably the right answer to that question (there will be a hard coded path in the executable which references libc for almost every working program out there in unix land). Or, that's how I would like to characterize the problem. And I think this thinking routinely applies in most all chroots. --Rdm 17:14, 10 November 2011 (UTC)