[asterisk-dev] [Code Review] 2922: ARI Recording: If the file already exists and ifExist is set to fail when we issue the command and we can verify it, issue a 409 instead of a success.

[David Lee]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2922/#review9938
-----------------------------------------------------------



/branches/12/res/res_stasis_recording.c
<https://reviewboard.asterisk.org/r/2922/#comment19177>

    I believe that a recording should fail if one exists with the same name, even if it is in a different format.
    
    Primarily, this is because are identified by the URI recording:{name}. If you could have multiple recordings with the same name but different formats, this gets complicated.
    
    There are also two potential future directions with the API which makes this behavior desirable.
    
    1. Recording into multiple formats simultaneously. Asterisk already supports this, but the API doesn't really expose it.
    2. Storing meta-data alongside the recording. This would likely be stored in a {name}.json file alongside the recording, and would be a problem if multiple recordings could have the same name.



/branches/12/res/res_stasis_recording.c
<https://reviewboard.asterisk.org/r/2922/#comment19178>

    Given my comment above, EEXIST is appropriate.
    
    The caller can know that if they get an EEXIST and didn't set if_exists to FAIL, then it's because the recording is currently in progress (and you should note that in the Doxygen doc).


- David Lee


On Oct. 16, 2013, 3:48 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2922/
> -----------------------------------------------------------
> 
> (Updated Oct. 16, 2013, 3:48 p.m.)
> 
> 
> Review request for Asterisk Developers, David Lee and kmoore.
> 
> 
> Bugs: ASTERISK-22623
>     https://issues.asterisk.org/jira/browse/ASTERISK-22623
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This affects both channel and bridge recording. Basically it just adds a simple check to make sure that the requested file doesn't already exist on the file system when we want to record. If it does, we set EEXIST on errno and return error. I went ahead and switched the errno value for when another live recording exists that uses the same base name to EAGAIN... not sure how appropriate that is.
> 
> I also added event models for Recording events, but nothing issues these events yet.  They'll be useful later.
> 
> I've written a test for this, which is in review here: https://reviewboard.asterisk.org/r/2921/
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/ari/ari_model_validators.h 400905 
>   /branches/12/res/ari/ari_model_validators.c 400905 
>   /branches/12/res/ari/resource_bridges.c 400905 
>   /branches/12/res/ari/resource_channels.c 400905 
>   /branches/12/res/res_ari_bridges.c 400905 
>   /branches/12/res/res_ari_channels.c 400905 
>   /branches/12/res/res_stasis_recording.c 400905 
>   /branches/12/rest-api/api-docs/bridges.json 400905 
>   /branches/12/rest-api/api-docs/channels.json 400905 
>   /branches/12/rest-api/api-docs/events.json 400905 
>   /branches/12/rest-api/api-docs/recordings.json 400905 
> 
> Diff: https://reviewboard.asterisk.org/r/2922/diff/
> 
> 
> Testing
> -------
> 
> I tested it manually with Swagger UI and attempted to record when a file existed where I wanted one and received the expected 409.  I also checked to make sure I would still succeed if ifExists was set to overwrite. I also checked for success when the file just didn't exist in the first place. I think that covers all my bases. All of these scenarios are also covered by the automated test in review 2921
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131017/ef633e8f/attachment-0001.html>