Some more questions
Hi Andre, Roelof Kemp came up with some questions/remarks on the ns_entry copy method: 1. The specs mention that a DoesNotExist exception is thrown when the target lies in a non-existing part of the name space. However, DoesNotExist is not listed in the "Throws" list. 2. What is supposed to happen when the source is a directory, the recursive flag is set, and the target is a file? I assume remove target, create target dir, and copy? And if overwrite flag is not set, throw AlreadyExists? 3. What is supposed to happen with a recursive copy where the overwrite flag is NOT set, and some of the destinations already exist? Copy to the non-existing destinations and throw AlreadyExists? Also, could you give Roelof access to the SAGA CVS? Cheers, Ceriel
Hi Ceriel, Roelof, Quoting [Ceriel Jacobs] (Oct 30 2007):
Hi Andre,
Roelof Kemp came up with some questions/remarks on the ns_entry copy method:
1. The specs mention that a DoesNotExist exception is thrown when the target lies in a non-existing part of the name space. However, DoesNotExist is not listed in the "Throws" list.
Right, thanks.
2. What is supposed to happen when the source is a directory, the recursive flag is set, and the target is a file? I assume remove target, create target dir, and copy? And if overwrite flag is not set, throw AlreadyExists?
Uhm, tough one! Unix shell would say: koks merzky /tmp : mkdir a koks merzky /tmp : touch a/a b koks merzky /tmp : cp -Rf a b cp: cannot overwrite non-directory `b' with directory `a' We don't have an exception for this. So, yes, I would concur with your interpretation: the target file should get removed, and a target dir with the same name should get created.
3. What is supposed to happen with a recursive copy where the overwrite flag is NOT set, and some of the destinations already exist? Copy to the non-existing destinations and throw AlreadyExists?
Puh, no idea! The POSIX C API has no recursive directory copy, and the POSIX shells have no notion of overwrite flags (only of !overwrite -- -f/--force has a slightly different meaning). I agree that your interpretation seems the most logical one, but I would assume that it would make sense not to make any assumptions on what files got copied before the exception gets raised. Also, the exception should name the target entry causing the trouble.
Also, could you give Roelof access to the SAGA CVS?
read access should be publicly available - let me know if there is trouble. I'd be really happy to give write access as well (active contributors are _really_ hard to find...), but I would also appreciate to know what his plans for writing the are :-) Cheers, Andre.
Cheers, Ceriel
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Andre,
2. What is supposed to happen when the source is a directory, the recursive flag is set, and the target is a file? I assume remove target, create target dir, and copy? And if overwrite flag is not set, throw AlreadyExists?
Uhm, tough one! Unix shell would say:
koks merzky /tmp : mkdir a koks merzky /tmp : touch a/a b koks merzky /tmp : cp -Rf a b cp: cannot overwrite non-directory `b' with directory `a'
We don't have an exception for this. So, yes, I would concur with your interpretation: the target file should get removed, and a target dir with the same name should get created.
Deleting a file in the case the user wanted to delete a directory is bad, IMHO. I'ld suggest to throw an AlreadyExists exeption.
3. What is supposed to happen with a recursive copy where the overwrite flag is NOT set, and some of the destinations already exist? Copy to the non-existing destinations and throw AlreadyExists?
Puh, no idea! The POSIX C API has no recursive directory copy, and the POSIX shells have no notion of overwrite flags (only of !overwrite -- -f/--force has a slightly different meaning).
I agree that your interpretation seems the most logical one, but I would assume that it would make sense not to make any assumptions on what files got copied before the exception gets raised. Also, the exception should name the target entry causing the trouble.
Agreed. Regards Hartmut
Hi, Quoting [Hartmut Kaiser] (Oct 30 2007):
Andre,
2. What is supposed to happen when the source is a directory, the recursive flag is set, and the target is a file? I assume remove target, create target dir, and copy? And if overwrite flag is not set, throw AlreadyExists?
Uhm, tough one! Unix shell would say:
koks merzky /tmp : mkdir a koks merzky /tmp : touch a/a b koks merzky /tmp : cp -Rf a b cp: cannot overwrite non-directory `b' with directory `a'
We don't have an exception for this. So, yes, I would concur with your interpretation: the target file should get removed, and a target dir with the same name should get created.
Deleting a file in the case the user wanted to delete a directory is bad, IMHO. I'ld suggest to throw an AlreadyExists exeption.
It would be nice to get another opinion to break the tie (I myself am not sure which way is better). Thanks, Andre. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
'Andre Merzky' wrote:
Hi,
Quoting [Hartmut Kaiser] (Oct 30 2007):
Andre,
2. What is supposed to happen when the source is a directory, the recursive flag is set, and the target is a file? I assume remove target, create target dir, and copy? And if overwrite flag is not set, throw AlreadyExists? Uhm, tough one! Unix shell would say:
koks merzky /tmp : mkdir a koks merzky /tmp : touch a/a b koks merzky /tmp : cp -Rf a b cp: cannot overwrite non-directory `b' with directory `a'
We don't have an exception for this. So, yes, I would concur with your interpretation: the target file should get removed, and a target dir with the same name should get created. Deleting a file in the case the user wanted to delete a directory is bad, IMHO. I'ld suggest to throw an AlreadyExists exeption.
It would be nice to get another opinion to break the tie (I myself am not sure which way is better).
OK, I thought about this now. Here is My opinion: I agree with Hartmut: throw an AlreadyExists exception, with a clarifying message, like "cannot overwrite non-directory `b' with directory `a'". I agree that deleting the file is a bad idea. If the user wants this, he/she should remove the file first. Ceriel
Cool. I clarify that in the spec Cheers, Andre. Quoting [Ceriel Jacobs] (Oct 31 2007):
From: Ceriel Jacobs <ceriel@cs.vu.nl> To: Andre Merzky <andre@merzky.net> CC: Hartmut Kaiser <hkaiser@cct.lsu.edu>, 'Roelof Kemp' <rkemp@cs.vu.nl>, saga-rg@ogf.org Subject: Re: [SAGA-RG] Some more questions
'Andre Merzky' wrote:
Hi,
Quoting [Hartmut Kaiser] (Oct 30 2007):
Andre,
2. What is supposed to happen when the source is a directory, the recursive flag is set, and the target is a file? I assume remove target, create target dir, and copy? And if overwrite flag is not set, throw AlreadyExists? Uhm, tough one! Unix shell would say:
koks merzky /tmp : mkdir a koks merzky /tmp : touch a/a b koks merzky /tmp : cp -Rf a b cp: cannot overwrite non-directory `b' with directory `a'
We don't have an exception for this. So, yes, I would concur with your interpretation: the target file should get removed, and a target dir with the same name should get created. Deleting a file in the case the user wanted to delete a directory is bad, IMHO. I'ld suggest to throw an AlreadyExists exeption.
It would be nice to get another opinion to break the tie (I myself am not sure which way is better).
OK, I thought about this now. Here is My opinion: I agree with Hartmut: throw an AlreadyExists exception, with a clarifying message, like "cannot overwrite non-directory `b' with directory `a'". I agree that deleting the file is a bad idea. If the user wants this, he/she should remove the file first.
Ceriel
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Andre Merzky wrote:
Also, could you give Roelof access to the SAGA CVS?
read access should be publicly available - let me know if there is trouble. I'd be really happy to give write access as well (active contributors are _really_ hard to find...), but I would also appreciate to know what his plans for writing the are :-)
Well, he is helping me implementing some of SAGA File and namespace on top of the JavaGAT, and may find errors or inconsistencies in the Java language bindings (which live in the SAGA-RG repository). Also, anonymous access does not seem to work? According to http://wiki.cct.lsu.edu/saga/space/CVS+Details, the following should work, with an empty password. ceriel@titan:~$ cvs -d :pserver:cvs_anon@cvs.cct.lsu.edu:/projects login Logging in to :pserver:cvs_anon@cvs.cct.lsu.edu:2401/projects CVS password: cvs login: authorization failed: server cvs.cct.lsu.edu rejected access to /projects for user cvs_anon Ceriel
Hi Ceriel, Roelof, Quoting [Ceriel Jacobs] (Oct 31 2007):
Andre Merzky wrote:
Also, could you give Roelof access to the SAGA CVS?
read access should be publicly available - let me know if there is trouble. I'd be really happy to give write access as well (active contributors are _really_ hard to find...), but I would also appreciate to know what his plans for writing the are :-)
Well, he is helping me implementing some of SAGA File and namespace on top of the JavaGAT, and may find errors or inconsistencies in the Java language bindings (which live in the SAGA-RG repository).
Ah, of course - its abound the binding, not the spec! No problem, I'll contact CCT support for CVS access.
Also, anonymous access does not seem to work? According to http://wiki.cct.lsu.edu/saga/space/CVS+Details, the following should work, with an empty password.
ceriel@titan:~$ cvs -d :pserver:cvs_anon@cvs.cct.lsu.edu:/projects login Logging in to :pserver:cvs_anon@cvs.cct.lsu.edu:2401/projects CVS password: cvs login: authorization failed: server cvs.cct.lsu.edu rejected access to /projects for user cvs_anon
The passwd is 'anon' - sorry for the misinformation on the page, I'll fix it. Cheers, Andre.
Ceriel
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
participants (4)
-
'Andre Merzky' -
Andre Merzky
-
Ceriel Jacobs -
Hartmut Kaiser